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ABSTRACT . ^ ' ' 

f This report presents the current state of tjie art of 

q6verhnient developed Data Element Dictionary/Directory (DED/D)' 
systems. DED/D«s are software t.ools used for managing and controlling 
inform^tipiT and data. The introduction of the report includes a list 
of the government agency systems surveyed and a sumnsiry matrix 
presenting each .system* s 'general characteristics. A comparative list 
focusing an .the technical characteristics of each system^ a narrative 
description highlighting e,ach system's special characteristic^ and 
Jbhe aqency»^s experience* with it'^ and scope note s^^and- definitions of 
the terms referred to ^^n the report are appendeC Information 
presented in this Report is intended to serve both the ^technical and 
administrative automated- d^ta processing community. ° (Author/JPF) 
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Qitring the past two Ndecades , *advances in inf oration processing and 
communication technologies haye 'substantially increased the ability 
of organizations to collect,, store, ^nld process data in -suppo.rt of 
a vast and ever increasing number of management programs. Along with 
this incr^sed^abj|lity has, come recognition of th^ need for automated 
tools to manage data^and information which in turn has led to a variety 
of software products. .This study was undertaken to provide a st^te-of- 
the-a,rt su'rvey of jdata element dictionary/directory systems developed 
by government agencies* . ' , 

This neport identifies data element dictionary/director}^ systems by 
tfame and source and provides a description of their features. Xhis, 
ini no.'*case, implies a recommend^ion or endorsement by the- National 
BuBeau of **iStandards nor should »this 'presentation be construed as^a 
certifiqation that any of tKesp systems provide the indicated capa- 
bilities. The information is presented as furnished b^r the partici-' 
pating agencies and has been reviewed by them fox accuracy and clarity. 
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ABSTRACT 



This report presents the current, staterof-the-art of government- * 
developed Data Element Dictionary/Directory (DED/D) systems* DED/D's ^ 
are software tools, used for manag;ing and controlling in/ojrmation and 
data. Eleven DED/D' systems are described, .firsT^ising a side-by-gide 
features, presentation approach, and followed by narrative syetems des- 
'eriptiotis which highlight special capabilities arid expediences with • 
each system, Infonoatioji presented *in* ^this re^^^rt is intended to serve 
both the-^chnical and adminlstratlVe ,'ADP bomihiinity, ' . 

'^''^ /. / ^\ ' ' . ' ^^^■'-^^^ , ' ^ I % 

Keywords: APtl; automated data' process ingl computer softwaVe; data 
element diction^¥^j*data element dictioinLary/dire<xtj^ data manag.eihent ;^ 
software tool, ' j I 

^ ■ - ' ' ■■ 

■ ■ ■ ' . I 

••I • . 
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1* Introduction * , ' ' ' " , ' ''^^ , 

An incr^sing awareness of the nee<} to matlage data resources has 
led to t-he development of systems that Identify, describe, define, 
and relate the basic unit of Infotmatlon, the data element. To 
'.<,8ain Insight Into thes^ systems, Federal Information Prpc^essing ' • 
Standards Task Group on. Data 'Element Dictionary (FIPS TG 17) was * 
given th6>itask of developing- guidelines f6r donstructiing d^ata 
element dictionaries/dijrectories' (DED/D'e), As 'a part of ^his 
effort, the task group is'cuFrently engaged in examining concepts , 
principles aad applications of 'data resource "management and data 
resource directories. Another of TG 17 's assignment 'is to ^.dentify , 
the relevant performance chanracterlstics of the ^automated p«)cesses 
designed to use and maintain DED/D's. 

The growing- neecf for .a tool to manage knd control data resources -has' 
already affected Government managers, mahy of -whom have developed 
and implemented DED/D's. Recognizing this, TG 17* established a sufc^ 
group -to research*, describe and compare as maily'of these Qovetijment 
PED/D systems as possible. Concurrently the Systen^and Software, , ^ 
Division, Institute for Computer Sciences and Technology, National 
Bureau of Standards (NBS) undertook to desci^lbe a representative set 
of commercially available DED/D's. The results, of .this effort are 
contained in NBS Special Publication 50p-3; Technical Profile of 
Seven Data Element Dictionary /Directory Systems. Because of th'e 
obvious pa|:allel between these two tasks, this document has J^een 
organized in a similar manner and draws upon material in NBS' Special 
Publication 500-3. ' • . . ' 

^ong tools for managing and'contr^ling dat^ resources , *five general 
capabilities have been identified: data catalog, data dictionary, 
data directory, data dictionary/directory, and 'data resource directory 
Since TG 17 wished to emphasize ^the' use '-of DED/D's as tools for the 
management of data as an organizational resource '-7 not as mechanical 
components of soft^are^ systems - it excluded software modules that are 
essentially file pre^ef^nition tools for data base management systems 
or file management packages but are frec^uently called dictionaries. 
•,TG 17 realized that nohe of the systems examined was exclusively a 
catalog,, dictionary, directory, or data resource direc1:ory, but a' 
hybrid of these capabilities. Nevertheless, car tain terms were found 
useful^ in portraying the orientation and scope of the DED/D with^ln an 
agency's data resource management program. Concepts^ In' data resource 
management are being explored in-depth by wording groups within TG 17. 



significant number o*f the ^gencies responding to TG 17 's initial 
request for participation had already implemented or were "in the 
p:;ocess of impl^entin§ DED/D's.- TG 17 decided to use these DED/t) 
Systems as the starting point^of this survey* The systems included 
cover a wide range of purposes and capabilities, and reject both 
differing philosophies of data management and di'f fering. levels of 
knowledge and experience in the field. , ' , ^ 

The purpose of this document is two«i£old: 1). to help the potential* 
u°ser in evaluating hi§ requirements for, a DED/D; and 2) to acquaint 
the reader wit,h a sampling of , existing ^systems ^nd the associated 
features, as representative of thfe stdtre-p^--the--art within the , ^ 
Govelmment .community* ' . - * ^ ^ V 

This is not an exhaustive list< of government DED/D Systems, but* it 
reflects a select;ion of representative sj^tems whi<jh TG-17 'reviewed,. 
Inclusion of a system does not imply^ recommendation or endorsement. 
Similatly^ omission of a s^steto^does »©^--iBiply that its capabil:feties' 
*are'les^s than those of an included system. ^ * > ♦ 

API SPED - Associate DireQforship' f oT Information jSystems 
Data i;iement Dictipnary . " ^ , 
^ , U.S. Civil Service Commission. ^ ^ 
' • * ^ 'm^ ^\ . ' . ■ 

ASCSDBD - Agriculture StabiaizatlTon and Conservation' , 
[ Service Data Ba^ Directory ^ 
- • Department of Agrici^ture 
\ ' ' Stabilization and^Cpns.ervation Service , 



DARCOM DED/SYSCAD - Army Materiel Development and 
, Read^iness Command Data Element 

Dictionary -and •System Control 
and Documentation ' ^ 
\ , / ' Department of Defense 

*' * Army Materiel Development- and 
K Readiness Command (DARCOM) 



DEMS - Data'Element Managements System ^ 

s Department of State ' o.' y 

Agency- for International Development (AID)» 

DLCS - Data Label Coirtrol System 

Department of Tr^ansportatioit. 
U.S. Coast Guard • - 



/ 



*DMB/DED - Department of Motor Vehicles Data Element Dictionary 
State of New York * * ' 

Department of Motor Vehicles " ^ ' *• 

X . FPCRIS,- Pederal Power Commission Regulatory Information Sysrtiem - 

Federal, Power 'Commission ' f ^ . 

' XOGDI^S - -Logistics' Data Resource Manageident System / * 

Department of -Defense . • « * ' « 

Office of th(B Secretary of Defense (DoD LOGDESMO) • 

STADgS^ - Navy ^^0 rid -wide Military Command and Control Systlfem 
Standard Data Element System , . 

Department ' of Defense * * - " 

. , Navy Regional Data ' ^ ^ 

' ' (NARDAC Washington Naval Shipyard) 

USDADBD U.S. Department of Agriculture Data Base 'Directory. \ »* 

department of Agriculture . e ' ■ ' 

•Office of Automated Data Systems , i 

' " Veterans Administratijon Data Dictionary 

Veterans Administration ^ • " ' . 

Documentation for all pfJihe above systems is generally 'available with 
thfe 'exception of FPCRIS ^^ch is in the implementation phase. 

The discussion on.^each system will be presented in jtwo sections: ^ . 

a feature l^st^which focuses^ on the technical characteristics\>f eacli 
system appears as Appendix A; 'and 2) a nan;ative systems description 
which focuses on the development* And implementation experiences o£ 
the impiementor appears as Appendix *C. Taken together, the feature 
list' and the narrative system, description represent a total DED/D 
system description. The featuife list presents objectively the technical 
charactAistfcs of the systems in a side-by-side format; thereby lending 
itself to comparative ,analysis/^ The narrative describes .the system in" 
terms of the problems., need^, and resources of the particular agency « * 

f<lr .which the DED/D was implemejited. In ''fact, it should be noted that 
each system narrative sftpuld be viewed only withlt\ the context. Further, 
it should be emphasizedSth^t the total system description is not, intended 
to serve ^s a guide to system implementation or seffection^ but as an ''^ 
example ox how common data management problems hs^ye been appro'ached 
through systematic definitiort of data resources and their interrelationships. 



^ This pu{>iHCcat:ion does not prescribe) or recotnmend a level of Implementa- 
tion nor a giv^n software system to any. particular user!'-? Instead, it 
suggests those factors which shduld be addressedjby an organization 
" interested in a DED/D system. Therefore j the reader should choos^ 
those factors which are^relevant in developing his own functional 

'requirements, design and performance specif icaT:ipns , , It sKoul^ be*^, 
emphasized' that it is ^.important for the reader-- to first define his 
own position as^ closely as possible and then attempt a solution b^Sed 
on ti^e experiences of those close tj^ that > position. 

A summary matrix* of tshe systems include^in this survey is -shown in 
Flgurfe 1 and presents their general .characteristics stich as: opera- 
tional mode, major hardware, degtee of implementation t^nd ihforma\:ional 
entities portrayed.; ■ * , ^, , 

Appendix E provides applicable d'efinftions of the terms * referenced in^ 
this publication. * ' • ^ ^ " » ^ ' 
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2* The Ddta Element Dlctionai^^lrectoVy as a Tool for^Data Management ^ 

The rgcent introduction of^the DED/4) hal^rovlHed management with an ' 
essential too^l to inventory, document, and- locate, ^.ts data resources, ^ ^ 
. thereby .pennlt ting the data to be managed as a resource' of the^organi- 
zation. • ^ . **. ^ * ' ^ ^ < * * * - ^ • 

Within this' new class of -tools, five general capabilities have heen 
ident^ified, that of: \ ^' ^ . , ' 

1. data catalog an organized listing, with or without a " 
description, by full name of all data elements ^used by 
an arganizatipn; ^ ' * - 

' , ' 2. data dictionary - an ordered collection of data element 

description^ containing specific identificationr attributes. 

3. data directory ^ an ordered collection of data element 
tiames, anS/or identifiers, and attributes which provide 

' JLocation of the elements. - 

4. data dictionary/directory - an ordered collection* of ^ ^ 
* data elements that combines ^the features of a <i^a catalog, 

data dictionary, and a data directory; 

' ^5. data resource directory - an ordered collection of * ^^"-^ 
\ Informational entity identifier? and their attributes ^ ' 

including those which .provide location and interrelktlon- 
' ship information* A data resource directory contains-.^ . 
many of the features of a dictionary/directory, tjut is 
not limited »to data elements insofar -as informational ' 
entity content Is concerned. c . ' * 

N; Sin^e most of ^he el*even government-developed systems ai:^,^of the 
data element die t ionjiry /directory , focus will be placed on this 
group. ' • . . ' . . ^ 

♦ NBS Special Publication 500-3 has ia^nt4.f ied* a set of characteristics 
for^ commercial DED/D's. The following subset of these characteristics > 
generally applies to.governm^t DED/D's surveyed by XG 17. These , 
."systems: ' , * ' ^ *1 *• 

^ 1. contain a unique Idfentif icatiqn, k set ofj physical characteristics 
. and 9 textual description of each of the data elements^ 

\ -.2. * show the relationships iqf elements ^o. each other and to other 
components of •the63y^stem,..^e.g.', programs, reports; 



A 



3. specify the source,, Ibcationv usage and d^stinatipiy-of '' * J-^^^ • ' 
•the elements; . ' - / ' ' ./ •' ' '( 

4. have validation ^jand redundancy-checking .capabilitjte?j ' 'A}}.- ■ 

■: >' ' '■ , 'i ;';/(^ J' , '• ■ 

5., coptain s'ecuH'ty .fifeguar^s to control the ac<:ess:ii41ity ^ • 
to the\data:elemeirt:S; ^' : ; • sff ''•■ri:'/.' 

•\ ". Up 11 m^'i 

6. have reportiftg/i^iiajjllities , such- a^^^ J ■/^•''' \ Mm 

#a. .predefihe^^^-^pient-oriented//S;tatis^ qr summarJ,'V I , 



b/ cross7ie%'renjce reports 



c. elemei|£:s usage ' reports , , 

audit/^trail reports, 
e», , change-effect; reports, 
f. error imports; 1 . 




rding, indexin'g, . 




7. have retrieyail .capabilities,, such as keywc 
.and online or batch 'querying. . \\' 

' - t - 7 - 

These government systems also contain 'ot;her features that distinguish''" ^ 
each one from the other. For example',; some sy^emi have online, inter- }\ ' 
active capabilities, and some are predomihatitlyNjatch systems. The'-'t: 
sur^eyed^DEn|D sy,Stems have as their: main- functions the control j'and ' ' 
mafiagemenfo^^ata elements. , Some ojt these, «;systeiiis atfe implemented' ' • • 
without dependence on a data, base ma^kgement systkm (DBMS). Howeve;r,. V" ' % 
there' are others that are implemented a^ applicWion systems iis'ing ' i • 
DBMS- software. Iri bo^h cases , the DED/D systems* functions are-not 
.secondary.,. to those of the DBMS., • - • ' . . /Z' 

NBS Special, Publication. 500-3 noted the fbllowiAg' tangible benefits 
that can .derived from the use 6f rfbED/D:' , '. ' ^ v • 

' * Simple and effective control of the da'ta'elemenljs.;'', • 

- ' ' ■ . * " *■''■' . 

* Reduction of data redundancy and" inconsistency; , - ' ' " ' " >• 

* Enforcement of standard, usage; ' .; ' „; 

'•^ ■ ■ .• •"• '- 

» *'EnforcCT|ent of security safeguards and' controlled accessibility • •'• 
of the data base; , ■ ' v '' 

* DeterminatW^of the Impac.t on^the fiotal^iilformation activity ' 
from changes Ifb; data elements T ^ ^ . . 



>1 



* Centralization &£^data" elements as an aid ^in design .and . * ' 
development of ijieV systems., " , ' 

* Consistency in documentation for data elements. , ♦ 

I ■ ^ . ■ ; ■ 

l^^ ^urvey of Gg^ernment DEt)/D Systems 
^ u ' ■ • ' ' • .. - ^ ■ 

MoStJof ;the descriptions of the systems, contained herein were provided 
by ^.tiVipants in the TG-17- effort. . 1 ' . 

A. questionnaire was developed to collecf %he general characteristics 
of tHiji^e systems.. Based ."on the re^sponse from each interviewed * 
patti^ipatiiig agency representative, a set of criteria ^for inclusidri 
was developed. '"The system had to: ' ^ 

1. be government-developed; ^ \ 

^ ^ . ^ . . ^ ' ' 

.2. be implemented, or in the process of being implemented ~ ;^ 

. np^^ust planned; ^ , „ , - >l>\u»i 

' " * ' • \ f ' ' . . ' .^^ 

3. ''perform" the functions of- a DED/D either at the element ^ 
level, or -at a higher level. . ^ '^yA 

Th^ information obt^iifed <t^bout eachsystem isypresented in this report ^ 
.first in a side-vby-side 'feature l±st^ format wnich consists mostly of \' 
short answers. Then it .is presented in narrative form, which elaborates 
on unique aspects of the systems, and includes experiential >elements of ■ ^ 
the development process. ^ ' * ' '.' I 

It should*Ke noted that the narrative systems descriptions are pres^t^;'j 
thay were originally submitted by the participating agencies with .Very^ 
minor stylistic or editorial changes. The content of these narrative 
descriptions may vary frotn, system to system since agencies emphasize 
different aspects of the DED/D. ■ \ • 

The scope-mates foi: the feature list, are reproduced in ^Append i:^ 9. It ^ J ^] 
shoul(f be emphasised that 'Me feature list represents .an objective reppift^* 
ing of technical characteristics of each system, and it is not meant * 
convey critical or subjective system comparisoirsv ^ | -^t* ' 

T(ie;feature list is organf^ii^ "under ^ the following seven major headings: , 



^ ^ 1, General Information; ' - . ' ; j/. ■ 

' ^ ... * Informatix>.n of a geAeral*i>ature.is included in this sec^icfR* 
» 2. ' System Features' - -Hardware ^vironmen^ * * ' s 

Information pn the hardwire environment in which th'e DED/D ^ 



Is imp l^ented, is -contain/d in this section. ' * - 

/ •' 
3. System Features Software /nvifonment • ^ • ' 

. , - ./ .. / 

Information about the/software requirements for the 
. , . . DED/DJLs , contained iA this section i , .. ~ ' ' 

^. System Features - UseyEnviroWent. ' * 

Information on t/chni/ques and caMilities available 
^<^to users -is pre/entld in this section. 

5. Data Element Attributes' Described by System » / 



Inf Qj^ation ibout th» character4;stics of a- (^kta .element 
as presentfediin-a DED/D is contained in th/s' section. ! 

- . • ,6. Eiement^qccurr^ces ifslfed ,^ -'^ ' ' ' ' ' . 

./Additional informati|oiQjx6ties wMch 'are/presented 
, V 'Within the DED/D are^^lstedt ^ ■ ' 

7. .Oiitput/Pro^lucts : .. <y 

. . . jj Typical, reports or ifroducts that cat/be'^oduced - bylihe 
• t;;:fppED/p ^^re listed injthis seatle^ ^ a oy tne 

iSrnfiivi?"'^^"^^ scope-noies for narrative systems descriptions. 
The. narratives have been organized in to, the f'ollowlng.sections: r-' 

Each^f th^_ D^^^ systems described is different in scope and approach, 

-J^r/ ? ^'''^''^"^^^^^^ ^^'i^^ "^^^ as-a.guide for structur 

ing descriptions of these systems. 

• Identification - *^ * * c* ^ ' " 

Information-on the ,title and toff ice of primary respansi- 
bility and on available -documentation Is- included In this- 
section. • ^ . * \ */ ' 



section 
2, Scope 



A; 



^ ^Reason, for imp Icemen t a tion, the iackgrojdnd an^S^story' 
Of the DED/j)'^4mplementation, and the ^ind ol ikplfemen- 
tatioh are^ ip(piudedirf this section, / 



3» ADP. Resources, (if needed) 



Hardware resources, including computer main frame, 
operating system, ^memory pize^ peripheral devices, 
special off line devices,/ software (whether special- 
ized or nonspecialized) , /and system utilities are 



in this- section! 
i^roducts ^ . ' I 



inclt»Jed 

4 

Content and Products 

liiformation on. dtata relationships ,1, organization of 



the DED/D,^ and standard! reports or products are 



listed in this section*.' "~ 

^^t' 'Vi 



V 



operational C6*nsidei;aJtions 

C - ^ 
Factors relevant to data collection' including source, 

procedure, operating mode for^ 

interface, with other systems^ 



method, edit, backup 
update and qiJfery, and 
are 'described 



6/ Security - - ^ 

^ . ■ .J 

. \ ^ , Restrictions on usja, 
* , Pf^ivacy Act consider^ 



Freedom of InTbrmatio'n, and 
ions are detailed. 



7. 



User Characteristics 



A description of the user organizations, and their 
functions, the data elements ,used and the reasons for 



using them. 
8. \ Costs (this section is , optional) * 

m ^ ^ , \ 

If available,, cost in dolvLars, and a description _of 
personnel commitment necessary to, implement and -run 
the DED/D. ' \ , 

9... General Comments • ^ 

Cpminents not fitting the above categories which the 
' propiofi'ents wish;., to make. 



4. . Summary 



.A 



,This publication has Identified technical features of data eleme^it 

. dictionary/directory systems (fiED/D systems) and has presented side- 
by-side desci;iptions bf I'l repi?€sentative govemment-devoloped 
systems. .?In*<addition,- n^frati^e descriptions highlight special 

^ capabilities and 'experiences with these systems, ' Other TG"17 efforts 
are directed tox^^ard developing jguidelines for future d^ta resources . 
management and dafa resource, dire'ctives . this^publication, however, 

•is* a presentation^ of the current status of government-developed • 
DED/D systems. It is hoped that- th;is practipal approach will aid 
prospective users to relate tlieir own situation to that of others 
who have evaluated and /or implemented syste&s, and to apply those 
factors which ^e relevant to their bwn set of circumstances. 



Information Qontained in both the feature list and narrative descrTp- 
t ions is intended to serve a. very wide range of userfe , -including' 
administrators, m^agers, analysts, programmers, ^spetialiats, and' 
technicians. * ^ < 

^It -should be .noted fchat^ although most dgencies woul^ be happy to * ' 
•provide available programs and doxiumentatiori, to other interested * 
agencies ~ either free of charge of for a nopi^al administrative 
change ~ these a^ncies are not .prepared to proyide maintenance 
for either "fixes' or' enhancements. The acquiring agency will be' 
"on it^ own," except for informal assistance. In^ .addition, 
documentation may be "sketchy or out of -datfe. »' , 

It is also of interest 'to nofce that one system, the DMV/DED is not 
automated, but a set of manual procedures, which incorporate manyj^ 
of the fe'atures^of the automated systems..- Further ASCSDBD and , 
LOGDBMS deal almost exclusively with documentirig information entity 
data bases and are conqerned with data elements onfy as, components 
of these data bases. 

The concept of viewing data as a resource has been growing in 
acceptance^ within the Federal? Government . The number, of .participants 
in this study, and th^ interest showfi in the work of ^IPS TG 17 
attest to the vital need for tools for man aging an d controlling data. 
Tha'systems surveyed cover a wide range of capabilities'.and re'flect N 
differing philosophies ^f data management and differing levels^of. 
.knowledge and experience In the field. * " " 



It Shoind he reiterated ^?that this publication does not presfcribe 
or recommend a level, of implementation b*r a' given softwa re system 
fto any potential user. However, it does poin^ to those^ f actors^ 
which should be considered. It is up to. the 'otentiaLaiser to 
choose those factors which ^,ate relevant. By studying existing 
sysfems, it beeomes possible to avoid pitfalls encountered by 
gthers, and t©. approach the problems of data management with 
po^ntial solutions in^hand* > Y * ' ' ' • ^' ' ' 



APPEMOIX A 
FEATURE LIST Of . 
OXTA EUHENT OICTICMARY/DIRCCTOftY 
(OED/d); SYSTEMS 
GENERAL INFOMtATION 



SYSTEM 
NAHC 



M)ISD{d 



^Asesoeo 



OARCOH^ 



Dies 



OHV/OED FKRIS 





L060RMS 



STAOeS 



USOAOBO 



VAOO 



OeVELI 



/ir.S. JUvy 
Facilities 
SystOK 
Office 

(FACSO), 



U.S. Departjyent 
of Agriculture 
Agriculture 
Sublllzatloo 
and Conservation 
Service (ASCS) 
Data Systois 
Division 



Hatertfcr 
Developaent ^ 
Readiness 
comand 
(DoO) 



Agency for 
International 
DevelOfNMnt * 
Office of Data 
Hinageaent, 
Infonutlon 
Hanageaent 
Division 



U.S. Coast 
Cuard 

InfofMtlon 

Systcus 

Division 



NY SUte Oept, 
of Hotor Veh, 
Data Standards 
fnd Controls 
Bureau 
Div. of Data 
Adalnlstratlon 



Federal Power 
Comlsslon * 
Office of 
Regulatory . 
Information 
Systems • and 
pjannlng 
ResUrch 



Office ortbe 
Asslsunt 
Secretarj^ of 
Defense 
(Installations 
and Logistics) 
DoO LOGDESMO 



U.S. Kavy OaU 

AutoMtlon 

CooMnd 

(NAVOAC) 

NAROAC 

Washington 

Naval Shipyard 



U.S. Departaent 
of Agriculture 
Office of 
AutoMted 
Systems 



Veterans Ad«. 
Dept. of Data 
Managehenl 
Privacy tnSj 
DaU Ad«. ' ^ 
Division '/^ 



ADDRESS 



OaU 8ase 
Adalhlstrator 
Bureiu of Man- 
power, InfonU' 
tlon Systais 
U.S. Civil Ser 
Coanlssloo r 
sh., U.C.2041S 



OaU Systeas 

DIvlUon 

ASCS 

USOA 

Washington* D.C. 

20250 . 



CoMander 
AutoMated 

Logistics^ 
Manageaent . 
Activity * : . 
Attn:DRXAL>DED( 
P^O. 9ox 1578 
St. Louis, MO. 



Lnfom^lon 
Hanagetimt CTIv. 
Offlte of OaU 
Manacfeiient AID 
Washington, D.C 
20523 - 



Infomatlon 
Systess Div. 
(G.flS/84) 
U.S. Coast 
Guard, 

400 7th St.NU 
Wash.. D.C. 
20590 ' 



Division of ' 
Data Adflilnlstra 
tlon, NY SUte 
Dept. of Motor 
Vehicles 
C«p1re Stat* 
Plaza 

Albany ""*^^ 
1222f 



Office of 
ReguUtory 
Info. Systess, 
Federal Power 
Coawlsslon 
600 n: CaplUI 
Street, N£ 
Wash., D. C- 
•20426 



Doa Logistics 
Data Eieaent 
Standardization 
I Hanagdient 
Office 
Room 7S69 
Hoffaan Bldg.'2» 
Alexandria, VA 
22332 



U.S, Kavy 
Regional 
DaU Auto> 
aatlon CenUr 
(KAROAC) 
81dg. 196 
Washington \ 
Naval Shipyard 
Wash.. D.C, 
20374 - 



Plans and 
Policy Div. 
OfTke of 
Autoaated Data 
'Systeas 
USOA 

Wash.. O.C. 
20250 4 



Privacy*& 
Data Ada. 
Division 
810 VeraonDr 
Ave., N.W. 
Wash.. D.C. 
?2d420 



CONTACT ' 
POINT 



OaU Base 

Adn1n1stratpir# 

(202)254-8887 



T. M. Kurlhara 
(202)447-4261 



Fernando 
PitenU 
AUTOVOMi 
% 698-6001 
CoMwrclal 
(314)2e8-60(n 



Carolyn Moore 
,(202)632-0084^ 



Chief 

Inforaa^tlpn 
Systeas Div 
(G-FIS/84) 
(202:.4?6-2438 



ttorren Crow 
(518)474-6871 



John H. Yiengei 
(202)2X5-493% 



Aaron Hochaan 
(703)325-9324 



Frank Tajler 
(202)433-35^1 



Roxanne 
Winiaw 

(202)447;2617.^ 



Chief. 
Privacy and 
Data Ada. 
Division 
|(202)389-3y()34 



AVAILABILITY 



On request 



On re<)uest 



On TK 



On request ' 



On request 



On request 



Not available 



Not available 
at present 



On request 



Not available 



DocuMntatlon 
on request 



TRANSFERRED 



i 
Yes 



No 



No 



No 



•No 



Yes 



Yes 



. No 



No 



.22 



svsTEH mims * c,omm harware enviromkcnt 



SYSTEM 
. KMC 



AOI 



* 



SYSTEM . 



R£(j^lk£MEKT 



PtWPHOlAtS 



OPERATIOMAi 
MOOC ' 



OTHER KAPOUARE 
.IHPtEHEIfTATIOM 



uniVac series 

70/45 



UNIVAC 
TOOOS 23 



I DISK 
3 TAPES • 
KXARO READER 
\ LINE PRINTER 
I PAGE PRINTER 
(OPTIONAL) 



BATCH 



HOHEYWELL 66/6C 
ISM 360/37D 



ASCSfifiO 



QARCOM 



IBM 360/50 



IBM 

OS/HVT/HASP 



2S0K 



I DISK 
4 TAPES ' 
1 LIf(£ PRINTER 



BATCH 



NONI 



IBM. 160/65 



IflMOS/MYT 



ISOIC 



2 DISK 

5 TAPES ' ~ 
1 CARD ReADCR 
I LINE PRINTER 



BATCH 



IBM 360/370 



«,OEMS 




IBM 360/65 



COC 3300 



IBM OS 



2 DISK . 
2 TAPES 
1 CARD PUNCH 
1 LINE PRINTER 



BATCH 



NONE 



^MA^TER 

_i_ 



20-4SK 
(24 BIT WORDS); 



I DISK • ■ 

4 TAPES 

1 LINE PRINTER 



BATCH UPDATE 
INTERACTIVE OR 
BATCH PUTPUT 



NONE 



FPCRIS 



t 

M 

A 

'N 
U 
A 
I 

S« 
V 

s 

T 
t 
M 



IBM 370/ T SB 



IBM MVS 
(VS2/EEL3) 



50K« 



1 OlSiC (WITH 
DYNAMIC o . 
AUOCATIONr 

1 TAPE DRIVE 

2 LIPE PRINTERS 



INTERACTIVE 
; OR BATCH * 



LOGDRMS STAOES UStiAOBO * VAOO 



IBM 360/65b 



250K 



I.DISK 

1 CARD REAOCR 
I iINC PRINTER 
4 OATA TERMIN 
ALS 
3 DESK TOP 
PR'NTfRS 



INTERACTIVE 
OR BATCH 



NONE 



HONEYUaL 6000 



HONEYWaL CCOS 



.25K* 



I TAPE 

3 TAPE DRIVES 
IXARO READER 
I LINE PRINTER 
I DATE TEftHIKAL 



Interactive 

OR BATCH 



UHIVAC 1)00. 
IBM 360/370 
CDC 6700 . > 



IBM 370/168 



I6M/VS2 fSQ 



300K* 



1 DISK . 
1 TAPE ' 
1 LINE PRINTER 
•OR TERMINAl 



, INTERACTIVE 
OR BATCH 



NONE 



IBfi 360/65 



IBM.OS/MVT 



1 DISK • . 
2-3 TAPC^ ^ 
laiNE PRINTER 
1 PACE PRINTER 
tOPTIOKAt) 



BATCH 



IBM 360/40 



'stSTEH fEATOUS • COMPUTER SOFmRE ENVIROIttfMT 



SYSTEN 



LAMCUAGE 


AUS COBOL 


ANS C060L 


ANScoea^ 

— ^ 


* *• 
Alts COBOL 

^. ' ^ 


ANS COfiOL^ 


HOT 
APPLICABLE 


MRNSYSTEM 

2000 
ANSI COBOL 


■* 

ALC/FORTRAN 
* 

♦ 


♦ 

ANS COBOL 

» 


4 

MRNSYSTEM 

2000 


ANS.C060L 


USE OTHER 
PCHS 


TCOS 23 
UTItlTIES 


OS UTILITIES 
HASP 


• 

OS UTILITIES 


UTILITY'^T 


NO 


NOT 

-APPLICABLE 


MEDIA 
TRANSUTE 
EDIT. LOAO^ > 
AUDIT. OUTPUT 
GENERATION ' ' 


HO 


♦ 

' ' MO 


*TS0-V$2 
UTILITIES 


UTILITY SORT 
UTILITY .PRIN 


use 06MS 

r — ^ 


^ HO 

\ 

0 > 


Nd 


^.^«- 
. ^HO 


;ho 


YES. be 
HARS-1U 


' HOT ' 
APPLICABLE 


YES. SYSTEH 
2000 


YES. ca 

M00£L~204 ' 


.NO 


%. SYSTEM 
2000 


NO 

t 


f iLt Acass^ ' 


SEQUEMTIAl 


^os v^xIm 


IS/M » 


SEQUENTIAL 


' RANOOM 

' ^ 0 


' WORD REFEREHtC 
LIST 


j)iR£a 


INVERTED List!v 


SEQUEHTIAL 

OR 
RANDOM 


DIRECT/LIST 


Wqoential 

* 


f ILE 
STRUCTURE 


SEQUENTTAl 


SEQUCKTIAl 

IHOEX . 
^ SEQUEMTIAl 


INDEX 

SEqUCNTIAl 

1 


SEQUENTIAL 


INVERTED LIST 


ALPHABETIC 


IHVERTEO ' 


Olfi^a ACCE^C^ 
LINKED LIST ^ 


INDEXED . 
''^SEQUEMTIAL 
' Oft 

DIREa ACCESS 
LINKED LIST 

4 


LINKED/LIST 


sequential^ 


FILE SACnjP/ 
RECOVERY 


Y£S ' 

& 

9. 


YES . 

• J. 


YES 


YES 


YES 


INOIVIOUAL*' 
DATA ELEMENTS 
HAVE BACKUP 
f ORDERS 


SYSTEM 2000 
FACILITY^ 


YES. CCA 
MODEL 204 ^ 


YES 


'system 2000 


BACKUP OF 
FRESr IS A 
PARTJOF THE 
JOB STREAM 













SYSTEM FEATUftCS - USER ENVIROmENT 



SYSTEH 
NAME 



AOISOED 



amm 

* umstu 



QUtRY« 

CAPABILIIV'^ 



FECHNiqUE 



OUTPUT rORN 



ASCSOED 



Fixed Fora 



ttflfted DCD/D 

AUo Operating 
Systen ja 



PredeflMd 



individual 
Update . 
Changes Only 
Specified 
Occurrence 



Hard Copy*^ 



OAfiCOM 



Fixed Font 



Operating 
Systca Ja* 



.Bauh 
Predefined 



Individual . 
Update 
Changes Only 
Specified 
Occurrence 



Hard Copy 



pElte 



Fixed For* 



Operating 
Systea Ja 



Batch 
Wjedeflned 



Allows Both 
Individual I 
and SIhgle 
Entry Update 



Hard Co^y 
Mlcrofora 



OLCS 



Fixed Fora 



Llalted'^OED/D 
Capability; 
Abo Operating 
Systen JCL 



Fixed Fora « 



Coaaand ^ 
Language * 
Written In 
Mars in 



Batch 
Predefined 




Hard Copy^ 



. Batch or 
Interactive 
Predefined 
and Ad Hoc 



Individual 

Update 

Flag^K 

Affected 

Entries 



Hard Copy 



OMVOED 



M 
A 
N 

U 

'a 

L 

*S 
Y 

S 

> T 

E 

< N 



Hard Coj^y 



FPCRIS 



Fixed or 
Free Fora 



Systol 2000 
Language 



LQCDRHS 



Fixed or 
Free Fora 



• STADES 



Fixed F9ra 



Model 204 

USER 

Language 



Batch and 
Online. 
Predefined 
and Ad-Hoc 



Individual 
and Single. 
Entry 

Update - 



Soft Copy(CftT> 
Kjird Copy 



Online 
Predefined 
and Ad-hoc 



Online 
Create (add) 
and Change 

Stngle 
Entry and 
Individual 
Update 



Soft Copy(cRT) 

Hard Copy 
(Printout) 

Kaghetic 
-Tape ^ 

Micro fora 
Froa Mignetlc 
Tape Using 
Com.' Tqulp 



RAS JII 
USER Language 



Batch and 
Online. 
Ad-Hoc and* 
Predefined 



Single Entry 
or Batch 
Individual 

UpdaU- 



-Sbft Copy (CRT) 
Hard Copy . 
(Printout) 
Magnetic Tape 



USDA06D 



Fixed or 
Free Fora 



Systea 2000 

Natural 

Language 



Batch, and 

Outlines; 
Ad'Hoc and 
Predefined 



Jndlvldua^l 
Update 

Changes only^ 
$pecl/ied 
Occurence - 



Hard Copy 



VAOD 



Fixed Fora 
Transactions 
Free Fora 
Description 



Operating 

Systea 

JCL 



Batch via 
Control Cards; 
Predefined 



Individual 
Update Changes 
Only Specified- 
Occurrence 



Hacd Copy 



. ■\ ■ 

SYSTEM 


^ AOISOCO ^ 




•MRCQH 


DA 

DOtS 


\ 

FA CLEXCirT AURI 
Dies. 


*^ * 

lUfES OCSdRlftEO BY 
* 

. OMYDCD 


* 

SYSTEM 
FKRIS* 


• » 

L06«MS 


* 

STAOES 


< 

USOADDO 


*7'. 

« 

\ 

VADO 




1-30 A/N 
CKARACTm 
LCfT JUSTIFIED 


i-so A/n 

CHMACTERS 
Un JUSTIFIED 


1-67 VN 
CHARACTERS 
LEFT JUSTIFIED 


CHARACTERS 
an JUSTIFIED 


1-30 

cHMuurrERs 

0 


r 

^ NO 
RESTRICTIONS 


250 CHARAaERS 
LEFT JUSTIFIED 


250 ' A/N 
CHARAaERS 
UFT JUSTIFIED 


700 A/N 
CHARACTERS 
L0T JUSTIFIED 
ID OCCURRENCES 
7D CHARACTERS 
EACH ' 


( NO 
RESTRICTIONS 


.'uvN r 

^CHARACTERS 
LEH JUSTIFIED 






Yt$ 


, Yts 


Yts. 


-Yts 


No , 


No 


Yts , 


• Jfes 


' Yts 


No 






Yts 


Yes 


Yts 


'J 

No 


Yts 0 
■% 


' Yts 


Yts 


Yes 

* > 


No' ^ 


Ves 


** 

ClurKter Type. 




Tet - 


Yts • 


Yts 


Yts 

1 


Yts 


Yts 


♦Yes ' 






Yes 




. Ye$ 

'' ♦ 


* 

Yts 


Ytt 


Yes 


. Yts 

A- 


Yts 


Yts 


Yes 

• 


, Yts ' 


- No 


• Yts 


• 

..JiMUflMUOfI . 


No 




.Yei. 


Mo 


\ 


* Yes 


\ 

Yts 


Yes 


Yes*. 


No ' 


\ NO • , 








Yes 




No 


Yts 

» 


Yts 


■ i 

Yes 


Yes 


No 


Yts 


' OeflnlMon/ 
^ OescrlpttoA 






Yts 


Yts 

4 


No 


/ 


^ts *^ 


Ves 


'Yei- 


No * 


Yts 


ltt1«t^oiisk1p 


'■'"\ 




Yts • 


Yts 


Yts 


Yts 


\ •'" ■ 


' Yt« 


YM 


No 


* Yts 


Ustr/(MMr 








No 


' Yts 


' ^»ts ' 




' Yes 
ft 


Yti 


Yts , 


Yts 




30 , 



N t. 



( 



ft 'V' 



O 



"■■ 

SYSTEM \ 


AOIS ' 
DTD 


■ oS* 


OMCON 


J OOCS 


9 

OUTPUT 

A ous • 


/PfiOOUCTS 
OMV 


* * 1* 

. f PC - 
RIS 


^OCMNS' . 


1' STADCS 


« 


♦ 

VAOO 


OtU Mct./91r. ' 




'Vti 


Vm 


Ym 


Oiroctory ^ 


Ym 


Ym 


* Yii 


Ym 


Ytf 


m 


Siflnfy/SUt. 




Ym 


YM 


Ym 


mi 


No ^ 


Ym 


Vm 


Ym 


^ Ym 


Ym 


. r 

mm 


V. .'-^ 


^'''^^^^ 
Yt«<; 


Ym < 


No 


Ym 


No 


. Ho 


* Ym 


Ym 


No 

*« 


No 


- ' i ^ 
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^ • APPENDIX B ■ , 

^ SCOPE-NOTES FOR 

- ■ * THE FEATURE LIST OF ' ' ^ 

■ ^ . DATA' ELEMENT DICTIONARY'/DlCTiONARY <DED/D) SYSTEMS 

(The Feature List is designed for "yes /no" and short answers — further 
explanatiojff are found in the "Narrative System D^sctipt^ons" in Appretidix C) . 

) , , ' • ' ^ • ' . 

GENERAL INFORMATION^ ' . • " 

, 1 ~ I . 

' SYSTEM NAM&S Name or acronym by which^ the DED/D is known.^ » 

' , & 

w, ^ . - ' ' ' " ' ' 

^< J)EVELOPER; Name of organizatioft that developed the DED/D. 

ADDRESS: Address of .deve'loper. 

CONTACT POINT: Name/Title and 'ph€>ne number of personfs) Or 'office to 
'^contact for fifrther information. 

AVAILABILITY: Availability of the DED/D system to other government 
^ organizations. # •/ • 



TRANSFERRED 



l_ Has a copy of the DED/D been implemen'ted^ln other government 



agencies? 

♦ l~' SYSTE^ FEATURES-COMPUTER HARDWARE ENVIRONMENT ' ' . . 

***** ^ , ' • • 

MAINKRAME : The type of computer that the DED/D is implemented on. (e.g., 
IBM 360, CDC 6'600). • • , v ^ / • , 

OPERATING SYSX^ ; The operating system under vhich the DED/D operate^, 
(e.g., OS/360>HJpivac 110? Exec II).. 

CORE REQUIREMENT : The amount of memory required to drive the DED/D.,* 

* • # . , . ^. . ' 

PERIPHERALS : The peripheral equipment required to ptocess *the DED/D; (e.g. 
number of disks required, the number of tape drives)* , 

OPERATIONAL, MGQE^ Mode in which the DED/D opetates, i.e., batch or inter- 
active. ' . * . .. • ' ^' 

OTHER HARDWARE IMPLEMENTATION » '►Has the DED/D system*been implemented on 
• other hardware?. * . . - * 

. „ , SYSTEM FEATURES-COMPUTER SOFTWARE ENVIRONMENT ^ 
PROGRAMMING LANGUAGE ; Major progfanmlng language- in which the. DED/D 



software i*s written. ^ , . 

USE OF OTHER PROGRAMS : , Note required programs,, which may be provided by 
the hpst system, needed to run the DED/D (e»g. sort-merge utility routine 
a tape utility routine; e^). 



USE DBMS ; Does the! DED/D require the use of a DBiiS for its principal* 
software? V * 

FILE ACCESS METHOD : What fil^e acce?Ss method does the DED/D use?, (e.g., , 
Index Sequential Access Method, Random A,cci&ss Method.) 

FILE STRUCTURE :" What file structure does the DED/D support? (e.g., ' ^ 
Sequential, '-'Direct Access, Linked List.)^ 

FILE -BACKUP /RECOVERY* : Does the DEE>/D h^ve its own backup and recovery 
capafii^ty? If not,* indicate other means. 

SYSTEM TEATURES-USER ENVIRONMENT ^ 

* 

INPU'F^liANGUAGE ; Does the input language require fixed-form or free-form 
transactions? Note other methods of input. 

COMMAND LANGUAGE : '^'Is th*e language a distinct capability of the DED/p, or 
A .does it rely on other means? * 

QUERY CAPABILITY : Is ^the DED/D query capability online or batch, prede- 
fined or ad-hdc? • • . ' 

UPPATING TECHNIQUE ; What Vind of file updating capability does the DED/D 
have? Is it "Single-entry" update, (the DED/D automatically updates 
every occurrence of the affected entry), or "Individual" update, (only 
^ the specified occurrence is, upd^ed, and outlier, occurrences have to be 
updated individually)? 

"S ' ' ' . • 

OUTPUT FORM: \ NcJte the physical farm of the DEDVd system output , -i.e. , . 
hardcopy (any, printed output), soft copy- (CRT). 

DAT A ELEMENT ATTRIBUTES 

NAME : Provide restrictions placed on the name of '€he data element (e;g. 
length, character type, justif icatioi\) . 

COBOL NAME ; " Does the, system , provide the capability t^ list the COBOL names 
of J:he elements documented?, . 

SYNONYMS ; Does the DED/D provide a word, an abbreviation or a phrase that 
. may.be usdd as a sub^itute for the data element name, conveying the^ 
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same meaning to the user? 

CHARACTER TYPE T Does the DE^/D have the papability of docuinenting the 
type^ of allowable, characters (e»g», alpha numeric, special) " used in 
expressing the content of a data .element? a- . * . 

LENGTH : Does the DED/D have the capability of documenting the lengflT . 
of a data element? ' v - 

JUSTIFICATION ; Does the DED/D hav^ the capability of xiocuijienting the 
^ justification of the data element? 

VALIDATION ; Does the^DED'/D document the' validation (or edit) criter'la, 
^liiicluding value range and other non-quantifiable validation techniques 
for the data element? . .* ' " " ^ 

DEFINITION/DESCRIPTION ; Does the DED/D provide the capability of defining 
or describing a data element? * / ^ 

^ ' : / ^ 

RELATIONSHIP : Does the DED/D provide the capabTI±ty for specifying the , 
relationship of a data element to another 'data element or to- a higher 
level entity? , * ' 

- ^ ■ ^ ' ' . ' jp 

USER/OWNER ; Does the DED/D provide the facility for indicating authorized 
useps (persons or files) or owners of dati elements? . ' • 

DOCUMENTATION OF DA^A ELEMENT OCCURRENCES 

PUBLICATION : Does the DED/D document the pubLication(s) wKich prescribes 
tlie use of the data .element^?, . " 

FORMS: Does th^" DED/D document the forms which use the data element? 

PROGRAMS : Does the DED/D document the computer programs which use the 
data eletnent'? 

REPORTS ; Does the DED/D documefft the manual .and/br Automatic xeports that 
use the data element? . i . 

SYSTEM : Does the DED/D document the applications and/or systems that ju.se 
tKe datk element? ' • , " • 1 • , 

FILEj - Does the DED/D 'document the files in which -the data ^element appears? 

. OUTPUT/PRODUCTS / 

DATA DICTIOlti^Y/DIRECTOm _ .Is the listing of the. Data Dictionary/Directory 
one df the DED/D' s fori^ products? . « . 
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SUMMARY/STATISTICAL' t Doea the system ^produce sutmnary «[tid ^atitftcal 
reports? * ^ . ' • . ' 



USAGE : Does the, DED/D piSofidjuce reports on user activity.? 

us ER- STRUCTURED ; Can users structute their :6vm reports on an.ad-ho.c 
basis? ■ ■ • ' ■ ' . , ^ •• ; ' 

CHANGE-EFFECT : Does the DED/D produce reports that tell the effects a . 
chan^^ in a data element (s) would have on all operational systems?^ * _ 

AUDIT TRAIL : Do*es the DED/D produce an audit-trail report (e.g.,, Who , 
changed .what element, when was the element created, ^en Vas the element,^ 
uDdated or edited)? * . " ^ ^ 

REDUNDANCY : Does the DED/D produce a redundancy (multiply d^fihed data ^ ^ 
elements) report? - ^ i : . » 

ERROR : Does it produce an error Cincluding inconsistency , in data elements) 
report? • ' • - - 

KWIC/KWOC INDICES; Does the DED/D have keyword-ln-context .(KWIC) or 

keyword-out-of-context (KWOC) indices capability? . ' >^^^ 

INDICES : Can it produce other indices in addition to KWIC 9r KWOC indices? 

CROS S -REFERENC E : ^Does the DED?D produce cross-reference reports', if so, 
how many types of cross-referencing reports can it produce? * 



PROGRAM I/O AREA : Can the DED/^. |>l^.^uce I/O area file descrjtptions^f or 
computer i>rograms? " » . «^ \ 

' . ; ^ • 

PROGRAM OR SYSTEK DOCUMENTATION l V.^ the DED/D . produce computer program^ 
information ;system dbcume'ntatiQn?)- ^ - ' 
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ASSOCIATE DIRECTORSHIP FOR. INFORMATION 
SYSTEM. DATA ELEMENT DICTIONARY 
U.S. 'Civil Service Commission 



I. Identification / . 

The U.S. Civil Service Commission's Bureau of Manpower Information 
^ Systems (BMIS) installed its Associate Directorship of Infprmation 
Systems (ADIS) data element^ dictionary* (DED) during the spring of 
19 its. It is the responsibility of the Dat^a Base Administrator 
\ ' (DBA). The phone number of the nDBA is (202) 254-9603 and the 

address for correspondence is U.S. Civil Service Commission, BMIS 
DBA, Room 6424, 1900 E St. N.W. Washington, D.C. 20415. 

For infoinnation, please contact: - * ► 

V 

U.S. Civil Service Commission ' ' 

BMIS Data' Base Administration ' ' 
: • Room 6410 F • ^ • \ 

. 1900. E Street N.W. 
_ Washington, D.C ♦ 20415 . 

Telephone: 202/254-8887 

» Documentation, in the form^of a brief . operations manual/, JCL, and 
an ANSI <:0B0L source list is^available to interested jgovemment 
offices. ' " 1 ' • • 

Iiy Scope ^ * ' - ' ^ - ' 



t0 



,BMIS*s purpose in. .Implementing the DED system was two-fold. It 
was intended to document all elements so that for the first time 
CSC would have a comprehensive, picture p,f how many elements it had 
and where, and how they were used. Also, Since the purchase of a 
new and 'touch larger computer'- facility was planned, the directory 
cpuld be'used^to analyze existing files and reports so that^ systems 
redesigned for the new 'computer could make optimal use of lata * 
resources. The system is intenfle^ to be both ^^^^'felexible means of - 
documenting present data, use^ and. an analysis tool Kr transition to 
a data basevdat^rfmanagement environments It is ba^caliy a dfbtion^xy- 
system, becausi its basic function is definition. H^Wer, it does 
pinpoint data element; use -in reports an4 files entlt^Si^an^^^ this 
extent can be considered •a limited data ditectbry^^^^^^^v;^*' 
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ADP Resources. 



The ADIS -data element dictiona];x j^>tecurrently instilled on CSC's 
Univac Series 70 (formerly RCA :SMra) 45 's running under; the TDOSV 
23 operating system. ADIS requir.es 46K bytes "of main memory, a 
single disk drive and two -tape driX^'e^ (an additional tkpe drive may 
be usfed in l;Leu of the disks), a b^rd^ :reader and a printer. : No 
special peripheral hardware , devices .are 'required but CSC uses a Xerox 
1200 off-line printing ^stemto prepare output products. 

The system's six computer programs , are written in ANS COBOL. All 
but .the first of Chesfe, a preprocessor fos. input transactions written 
by CSC, were obtained,- from 'Faciliti^s^rSystems Of fide (FACSO) NCBC Poff 
Hueneije, California'; The five basi.aj|.i:ogra&s tonsist of edit, update, 
and three report generation programs..'- "esc'st-implementatiort of this 
system is in the public domain, and' CSC would be happy to provide 
interested parties with its software. 

In addition to the above software, a card to tape utility, a para- 

'^f'^^'-Jl^'^^ 's°^^> and a tape to print p.rogram are required to execute 
^ the ADIS DED. / . 

•' r 

The proprietary report geneorafion and file managem4nt product, 
Easytrieve, from Pansophic Systems Inc. has been used with ADtS ' 
ri^-es to generate ad hoc reports . ' • 

Content and Products • o . »^ . 

Several data en"tities are described by the ADIS DED'. These, are 
representation sets (groups of elements sharing common representa- • • ' 
tions), data elements, data code tables, files, and reports.' TK^^- , " 
entities axe related in the followir^ way : elements and reprfisenta- 
tion^sets are interchangeable, ot'he^ntities subordinate. 
^ ' ^ ■ . • ' " , . / ' ; ^ 

The ADIS^ DED master (file^ is a magnetic "tape, file sequenced by'recdrB*^ ' 
type within data elerifent or reprersentation set I.D. There is no 
sin-gle master record which contains all-data ab«ut a ?ingle data 
element. Rather,, 11 separate \Ed&ed length record types, each of * 
'Which contains different types 'o'f information and'each-'o-f which may 
have 99 occurrences, are grouped behind a sin'gle data element -record. 
Record format A describes, 'reprersentation sets and data .elements and 
contains an ID. number, title , Xt^^idardi^tion £fidicator,. .mnemonic, 
size, chardcteristic (alphabetic, numeric, ^alpha-numeric) code, type 
(elements collected on/ individual employees'.-^tt^ positions, or on - 
aggregates of position- or''employee)., a format code (indicating 
whether an alement^contains literal ijata or is ,toded), and a" standard- 
ization status code. '/^ ^- > . 





Record format B describees files'and indicates file name, numbe^ 
location. of the elements within the file,* and whether or not the 
subject element is a 'key field or not.. Record C covers synonyms 
for the element name. Record D allows up* to 98 representations 
of *a code' set to be defined while Record E allows up to *5,800 
characters of definition of a Representation set or element' to ' 
be entered.* Ilecord F, G, and H indicate element usage, edit ^ 
criteria, arid source respectively and,, R^.cord I contains reports , - 
.sj^bol, number and' title for all reports in which' the. element 
appears. ^ /\ • - * ' 

There are approximately 2,^00 data elements entered In .the'DED^ - 
described by 'about 10,000 records or an average of 5 physical-*^" 
records per element. Access to these records is- sequenti^' The - 
various ADIS DED outputs are created by sorting records in various^ 
sequences involving record type -and data element ID and then iS^r 
ing them through a master index program. * ' ' 

The chief product produced by the ADIS DED is a dictionary which ' ^ 
lists for each elfement: its I.D. number; mam^ size; classi^ 
synonyms, acronyms; the titles.;jnd I.D. numbers, and loc^ti^h of 
the element within all files in which the elemen1:*>is used; a nar- 
rative description ^f the element? and its' users. A remarks area 
is, also available.^ The dictionary contains <one page, per element; 
pages are produced on an'^s changed basis.: These' pages >re printed 
in I.D. .number sequence and bound ittva loose-leaf fashion sa-that 
when an eleme^^t's information changes, its entire page can be easily 
printed and ^fepiaced. '^^ ■ , *^ * 

Several indexes are also produced in addition to the dictionary. 
The first of these lists, for each repo'rt',^ its constituent elements. 
*The second lists, the same Information for ^aH fil^es, trtth the - ' 

elements listed both in location order and alphabetic order ^ 
third index simply lists all element nam^s. in alphabetic4 order and 
a fourth^ lists, the names in order of I.D. number. A fifth is ^Y^il"" 
able in mnemonic- sequence. A compressed dictionary ^ is also .produced 
which; unlike the main dictionary, concatefiates several element 
entries on the single page. A list of elements in"^ alphabetic order 
shows all files on which each dement occurs. The oirly remaining 
standard product is. a transactibn edit' listing. ' 

/The use of Easytrieve for ad hoc retrieval^ l^as been mentJoaed 
before.* The only difficulty experienced to date with thi^^ approach - 
has-been the f ragmen te(^ DED/file structure which doe/ not lend-, itself, 
4;o easy file* manipulation* ' ^ . - 

' ' ^ ' ^ . . . . 
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Operational Consideration > " * ^ ^ * 

The source of the^data which has been entered into ^ADIS thus. far/ 

has been system documentation where it existed, supplemented by * 

face to face contact with the ADP systems analyst responsible. 

for the various systems covered. '"The information gathering effort 

was phased in two ways,^>e., it not oi^ly proceeded, on the 'system 

by system basis but on a £ield by^ field basis. Iii' other words, the 

first phase aimed at collecting ^identif ication 4ata about elements 

in selected systems. . It was not until this ef f ort;,i»;vjas complete 

that* other'^ application systems and ^supplemental elemenjt and repre^ 

sentation set information, w,as coded -arid entered.' ^ 

♦ • * > ' 

The personnel used to code the data^ entered came^from both ADP and^ 
ADP user org^iz^tions. ^1 shared a data management orientation 
and all work was coordinated 'by Data Base Administration. Working' ^ 
from existing documentation and through interviews with data users, 
' the DRDj^data base was accummulated over a period of 9 months. 

Data integrity was addressed by having it collected by a' team of pro- 
^fessionals who knew with consistency what, information they neet^ed. 
Further, after the creation of the first reports and files a' second 
go round was undertaken as a review so that corrections could be m*add. 
Those persons- interviewed initially were allowed to criticize .the ,pi?o- 
ducts and to indicate where changes should- be made". 

The AI)IS edit program edits for completeness of information, not^for. 
validity. An effort will be made' to establish more complete validity 
and relational edits. Back-up to files is provided through retention, 
of father and grandfa^Ker mas.ter files and associated transaction 
tapes* 



All ADIS DED update, report generation, and query operations are 
.performed in batch*' mode, usually overnight. 

* * * >. ' * 

Security ' * - ' • 

Access to ADlS is monit(>red and approved^ by the Data Base Administrator 
although the^only current users are the .Data Basfe Administrator, the 
Data Standardization Section, and an ADP user, the System Development 
Division of^ the Bureau of Retirement, and Insurante and Occupational' , 
Health (BRIOH) . All, updates and Requests" for standard repoifts vnnsl '.^^ 
be submitted through DBA at ^least during -the system's present state 
of development/ . • - . ? 1 . * 



if 
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No security restriaints are imposed .on the produc£fe and they are 
generally -available. Subsets of the main fil^^nave also been 
created ^r spjecial purpose query and reporfef^ activitx for Submission 
outside of the DBA^s area. The purpose of fe^ie security that exists 
is data integrity, not restriction of knowledge^about content 

VII. User - Ghayacteristics ' ' * ' - 

The present users of the directory are DBA and the Data Standardization, 
Section and Bj^IOH.* • . , 

DBA has been cencerned since its establishment with the differing 
forms of the skme data as us-ed throughput the Ciyil Service Commission. 
DBA's primary use ot the DED has«ybeen to identify and document where • 
data is used and where ^it. is inconsistent. The DED has already. been 
extremely useful, in identifying differing forms of the same data and 

* each user of it. " ^ -. * 

The Data Standardization Section of the Manpower. Systems Management 
* Division carries- responsibility for developing govefnmenfc-wide^ 
* standards for personnel dat^^lemerits .' The ADIS DED has been. used >y 
them ^s a tool for developing and* documenting the definition of these" 
•data elements and^as an automated repository for the information 
needed to publish the Feder^KP^rsonnel Manual (FPM^ Supplement 292-1. 
which deals with data element s^tandards for persojij^ data. 

' BRIOH has been using the DED as a means of documenting the data^. 
'Elements It'uses in its'own systems. It is developing a comprehensive 

* .picture of the jiata It uses in znaintainiri^^^he Civil Service Retire- 
ment System. ' i ^ 



Each of these organizations, DBA, PSS, and BRJOH, although they haVe 
differing perspective on data., resource management:, have found means; 
to use a common system. At %S(:, it it almost 'tek tain ^ that system 
designers and DP management, especially of systems design activities, 
will also become heavy users of the AJJIS^'DED. /-* - * 
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U.S. Department of,, Agriculture 
Agriculture Stabilization and Conservation 'Service 




USDA ASCS DBD 



IDENTIFICATION 



fhe USDA Agriculture 'Stabilization and Conservation Service (ASCS) 
Data 5ase Direc^^ry <DBD) was developed in 1973 to support the 
development o'f the ASCS Integrate<| System Project; ^ The de^lopment 
of the ASeS DBD was done under the direction of the: 

Data Systems Division ^ f * " 

Agriculture Stabilization and Conservatiqn Service 
If* S. Departiment of Agriculture 20250 

/ . ■ w . ' 

Tpm Kurihara^of the Technical Resources Staff of the Data Systems 
Division is the contact point for information -concerning tlie ASCS 
DBD (202/447-6261). * " <\ 



The ASCS D^ is no longer operational due to a change in Agency 
plans/ The ASCS Integrated System Project for which the ASCS DBD 
was developed to support was called- off. 

The ASCS DBD is being described here dn order to present the dlslL^ 
features that were contained in the system". ^The original document-^ 
ation includes a functional description, system and,prbgraB(':Sp&s;i^*^ 
fications , user -manual, and COBOL programs'; Some documentation is 
readlly> available * fqj: example, input f^rms and sampie.^reports. 
More detlailed documentation requests will also be met if practical. 
(Tom •KuriKa^a:*^02/447-626iy. ■ 

^ \. ^ -^^ ' '^^ 

SCOPE • . . • > 

The objectives and operational uses for which the^CS DBD was 
developed in^^upport'of the ASCS Integrated System Project* were* to * 
provide tt 



A. capability to record data requirements,' , /• * * 

. A capability to collect, standardize, an4' control data '< 
attributes /(sttoh as*data ^l^ment ^i2e, ciasjs, COBOL name, 
' .^etc), ' - * . . • 

. A. capatfiiity to support" system analysis (includingka KWXC * 
/Index capability),' " - -^^^^ ' J- V ^ 

. , ■ - ■ ' ■ ' ''■/. \ 'v-y - ■.• ; 

To identify coiHmohalities^.(for the - purpose of combining), 
' .* To identifj^ redundancies (for the. purpose pf singularizing) , 
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* To identify^system/subsystem fnter^latioftships, * 

~ * To enable statistical analysis of workload in ^conjunction 
with the Erogram Directory (The ASCS JBD .provided -v^olume * 
information whereas the Program Directory provided frequency 
information). y 

A capability for recording and controliing data element \odes i 
.ai\d their representative values, - ^ \ * 

A capability to compute dat^ storage xequiremerits 
-:(in three forms: ^raw" characters, "packed numeric, 
and with a null-valufe compression). 




,.A capability^ to assist in developing System design-"' . 
and program specif icati^jns , and 

*^ A capability to ass*ist -in/coding or generating the 
, Data Description Language' (D^L). f,or a D3MS. - 

The ASCS DBD was developed in-house and was operational in 1974 and 
1975. The ASC^ DBD was a dictionary level implementation. -During 
the perimi in which'^T^as operational, the ASCS DBD .maintained 
6000+ data elements, 1200 + 'data^aggregates, and 400"^+ logical 
files. 



1^ 

. / • - .•■ 

ADP RESOURCES 

The ASCS DBD was operatioipal on an IBM 360/50 and ran in a ba 
environment under OS. The programs were written, in ANSI, COBO: 
used the 05 access methods, sequential .and' Indexed sequential 
methods', (SAM and ISAjM>. ' " 

CONTENTS AND PRODUCTS 

The data relationships described in .the ASCS DBl) were at tliree * 
levels— data elementa, data 'aggregates , and 'logical file*. The' '^^^ 
three -entity levels were fully integrated with ISAM chainsi Connect- 
ing all entities. ^Definitions of the three levels* we^^s^follows : 




The data element \i^as thfe lowest level, of --th^^ ASCS DBD data 
base hierarcljy ^<r. possessed a unique number,' najne., ^d % 
other attributes. It was ' the,^smallest unit of.^"data s.trffig 
that could be accessed. .(Example: ASCS FARMER IDENTIFI- 
CATION NUMBER>. ^ - ... 



The d^ta aggregate Was the middle level af the ASCS DBD 
•data base hierarchy and. possessed a unique number, nam^'» 
and other attributes. It was * compos ejf of data elements, ^ 
ofis^bordiriSte data aggregates, or a- combination of the^ 
two.' (Example: ASCS FARM KEY~composed of 3 data .elenjjents ; 
(1) STATE CODE, (2) COUNTY CODE, and (3) ASCS FAJRM WJMHER),. 



• . The logical file was the highest level of the ASCS. DBD 
^ata base -hierarchy .and possessed a unique'number.,' name, 
and other attributes. It was composed of records containing, 
data elements, data aggregates, or a combination o£ the two. 
A logical file, could contain more than one* record-type, 
(Example: ASCS FA^FILE)'. ^ . • * 

\ ' ^ : 

The A9CS DBD was organized tsp express membership /ownership relation- 
ships in terms o»f residency and constituency . The ASCS DBD possessed 
chains moving upward to describe residency , °> i,^e, ,^the concept that a 
data element J'resided^ in a h'igher* level such as a data aggregate^ or 
in a record of a logical file, e.g., / 

' LOGICAL FILE ' , ; .* ^ 

DATA- AGGREGATES \ 

" , ' , ' DATA aMiEGATE?* ' = ' , ' 

■ > ' -' DATA AGGREGATE!' ' « - ' • 5"' ~ 

, " .""vj^ ei^ment;^^^ y ^ •, » ' ■ 

The ASCS DBD also_j)ossai^sed chain^mpving "dotrnwaEti J£o describe 
cOnstltuency^ ''^g. , g logical file» co|itadjn&a'''re1a6rSs- wftlch were 
comprised of "constitugre' ,'' lower level entiti^s'^su^h as^daia 
aggregates and data eletjents,' e.g;«, ^ ., . . ~ 

^ -LOGICAL FILE ■ • "*- \, 

'• ^ ^ 

DATA AGGREGATES ^ • ■ 

y * DATA AGGREGATE2 - 

. DATA AGGREGATEl 
/ ■ DATA ELEMENT 
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The three master files tfsed" to house the ASCS DBD were stored in 
two versions — a sequential version, used for updating and normal 
.reporting and an indexed sequential ^fersion used for creating the 
return *side of the chain, for checking for chain consisteAcy ^and 
for use in specialized reporting* ^ 

The ASCS DBD provided a yariety of reporting support.- . The update 
segment provided a transaction register, .edit and update etrcfr^ 
reports, and the three basic directories, the Data Element Directory, 
the Data Aggregate Directory, and the Logical File Directory* COBOL 
names for the three levels were .generated by removing special i 
characters, inserting hyphens, and ^ifUncating at .30 characters* A - 
table of standard ASCS abbreviations was also used for substitution 
purposes* The T.ogical maintenance segment proviHed the checking of 
chain consistency and the generation or removal of the return chain * 
when nnw entities were ^either added or^ deleted* The analytical #r 
support segment provided a nfimber of system analysis reports* 

.Extracts were made based on subsys^tems and segments: within subsystem 
^.as well as at lower levels. Analytical repoKts were provided to 
denote inter-relationships among s«^ystems arid segments* Qftfe 
^report provided a ranking as to which logical file€,4dSta aggre- 
gates, and data- elements were accessed the most* This report was 
provided by interfacing with the frequency information contained 
in the Program Directory* This report was particularly beneficial 
to the dajta ba§e administration function, e*g*, in*the structuring 
of data and the assignment of keys*^ 'Another analytical report pi?o-- 
vided storage requirements of ther'data'as specified in the ASCS I)BD 
.in seyeral computational formats* " ' . • / ' 



V* OPERATIONAL CONSIDERATIONS 



The data collection- ef fo|^ was initially done by task forces,.* called 
Specif ication Teams (Spec-Tfeams) , 'organized ^long^ubsystem lines** 
Eadh* subsystem Spec-Teto had a data specialist* who was responsible 
. for recording the data elements, data aggregates, and logical files ; 
needed .to support t.he system requirements being specified for the 
subsystem. There were nine inpjiit forms used — a .three-page set for 
\ each data element; a three-page set for each data a^regate, and a 
^three-pLage set for each logical file* All data was- etit^ed via 
keypunching* ' * ^ * ^ " J 

The. overall coordination of the data sp^^cialists and the data i 
specification. effort was the responsibility of the data base admin- 
istrator and' hils staff* This coordination function included the 
'control and assignment of numbers^'for each 'data element, data 
aggregate, and logical file specified for the ASCS' DBD.* (The numbSr 
Included codes for breakout by s^b^ystem and segment) * . Another 
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important function <?f the data base administrator was- to identify 
redimdancies' and to. combine or singularize as neejpd (for purposes 
of assigning^the system arid •segment portions o^ a number, e;g.,^a 
data aggregate numberi, that was used by more than one system, the 
data liggregate would be assigned during the singxllarization process 
r->^to a primary subsystem, and segment)". 



The ASCS DBD iiiterfaced with an ASCS Program Directory which con- 
tained ir 
programs. 



tained information describing ' subsystems, segments^ and computer 
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The data in regard to computer programs included frequency informa- 
tion which wlien combined with volume .ihformation from the ASCS DBD 
was able to provide a statistical analysis of the workload. 

/'VI.' SECURITf ' " <• - •'../' . > 

* \ * , * 

The .ASCS DBD itself had no security^ provisions beyond the normal OS 
security capability provided for OS data sets, ' ^ 

The attribute^ that were collected for each data element and data 
aggregate did includes privacy/ security classification as ,tp which 
^ users had "jread" authorization, which had " read/ write" ^authorization ^ 
,^.and wKich had ^either; authorization. The codes <iisBd to Ttdentif y 

user orga^iizations* included a prefix to denotd the "records-holding" 
o user. , * 9 ^ ^ " ' . ' ' . ♦ 

VIK USER CHARACTERISTICS - 

The user had an active and controlling role in the entire ASCS 
^ Intergrated System Project. , It was during the Us^ Requirements 
^ Specification phase that the data reljuirements were identified apd , 
specified for the ASCS DBD; These Spec-Teams' were carefully chosen 
^ to includ^ thje /various representative interests, and were chaired in 
4II case9|i)7 ^ser personnel. * . ^ . - 

The ASCS CBD'was designed, as a ^ool Wit AD? personnel^nd' was not 
nomally "clistTibutefd to- user ^Divisions. ' 

VIII. COST . • * . 

the ASC§ OBD was developed in-house and maintained under the data 
base ^administrator function._It was operated in a batch mode ins^one ; 
of the Deparjtment of Agrictiltufie's Computer Centers.' tfhe 4ata 
collection for the ASCS. DBD was initially done as a by-product of 14* ' 
Spec-teams that had been established during an early phase of the * 
development' cycle. Refinements, updates, and o^her changes to the 
ASCS DBD were , accomplished 'as the system development continued. (The 
ASCS DBtf was- successful d(Q a vehicle to establish change control of - 
data attribfiti?#.y . * ^ \ . 

* - • . . 36 - ASCSDBD 
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Approximately eight system' ana^ts and programmers participated 
part-time in the actual design, programming, and procedural develop- 
ment of the ASCS DBD svstem, * *^ 

GENERAL COMMENTS ' 

The ASCS DBD experience suggests several concfusions: 

/ Unquestionably, a DBD provides a convenient vehicle for 
collecting, standardizing, and effecting 'change control of 
an organization's data and its attributes* 

4 

For systems under-development , a DBD should be established 
early in a development phase .to^ assist the designers of the 
, system, -' • 



A DBD is an awkward and cumbersome thing when Implemented 
in government agencies or l#rge sub-agencies such as ASCS, 
The number, complexity, and multiple functional aspects of 
the marfy ASCS programs, many of a disjunct nature, causes 
data base management--^ be an immense challenge. 

The ASCS DBD generated mountains^ of paper: (Future ASCS 
. plans had been made to go< to COM or CRT display output,) 

Since commercial softrare products are typically marketed.^ 
at a fraction of development cost, the ASCS experience would 
further suggest that purchasing of one of the available 
commercial packages would be a preferable course of a^ctijn^ 
In^house DBDs ^frequently have a 'tendency to n^Ver reach ' 
^ completion status. In the ASCS cas^, new capabilities. wer^ 
constantly being added -until" the system grew beyond 
recognition ^ of at. least ojie of its original designers. 
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IDENTIFICATION . , -/ ^ ^ 

,The US Army Materiel Development and Readiness Command (DARCOM) Data 
Element Dictionary (bED) and System Contr<ol and Documentation 
-(SYSCAD) syst^alB were developed by the US* Anny. Automated Logisi^ics 
Management^^^stems Activity (ALMSA) to sUpport the development, 
docuifiSntation, fielding#and control of' a large, intejgrated, standard 
wholesale logistics management system identified as the^ Commodity 
Command* Standard System (CCSS)» The proponent foi; these systems 
is: . ^, . 

Commander ^ , 

US. Army Automated' Logistics Management 
, . ^Systems Activity ^ *^ • - ^ 

' . ^ATTN: DRXAL--ID^ (DED-Femando Puente) ' 
'PO Box 1578 
St •-Louis, MO 63188 ^ ' 

Telephbnes"are AUTOVON 698-6001 ox Commercial 314-268-6001 • 

System documentatTon is int^rnally'tflevelo^ed and raaintaiiied-t The 
input documentation for the BED is ,DARCOM-R 18-5, Vol 4, Methods and 
Standards^-Data Elemeift^ and Codes Standardization Program • 

SCOPE, * - \ . ' 

Early in the planning ^nd development stages of the CCSS design, the 
c'hallenge. and' need ^or data el^ement s^tandard j.zationj^was recognized, 
partiaularly as it related, to the integrated storag^e and file' ' 
orga'nizatioQ principl'^s that were to be .used. A single* authorita- 
tive document for use as a communication iink between the sj^stem 
designers, computer, systems analyst, programmers, and 'subj-ect matter 
specialists was recognized as Ueing required, (hic of these basic 
requirements*, the DARGOM Data Element Dictionary/Directory* system 
began to evolve". The first version of .^e DED system was imple- 
mented ^ early 1967. Its primary purpose was to produce an author- 
itative document for use by all funct^oifal and computer oriented 
personnel who were designing and programming the CCSS. The- diction- 
ary consisted of data elem^n^/data field descriptions that ^ncluded 
*st^ndard names, programmitig mnei^onics, definitions, automated ^ata 
processing ch^aracteristics of the data, and the regulatory reference 
and authority for the entry. Alsb included was "where» us^d*" data, as 
it related to identifiable cells a^d subcells withiA the system 
which equated to maji>r* tasks and ^ub-tasks which were jto be automat'- 
ed and integrated within '.the logistics system. The data elements 
that were entered in the -pED data base were primarily developed by a 
committee of funCy tionalJ Ly^ oriented subject matter specialists, with 
the assistance of computer/systems analysts* Contrjol of the project 
was exercised by one organizational division- which was charged with 
coordinating and controlling the total CC^S: systems design. 
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The development of the basic data entries for the* dictionary involved 
a gr&t deal of coordina'tion and discu'ssion between the functionally 
oriented Subject matter specialists. Many of the basic data entries ' 
that were developed crossed funct^QnaX area boundaries and in some 
cases were referred to by differii^g names or •had slightly differing 
> contextual definitions. Before a data element entry was acqepted * 
for input int^the DED data base, all functional representatives on 
the committee were required to sign off on the entry as being^ f, 
correct and required by the system. All 'entries entered intcf the , 
DED were assigned a functional proponent who'was given the respon- . 
sibility for maintenance after it was ^entered into the data base. 
The DED that was produced became the communication' link between^all • 
the personnel involved in the syst^ development. Be.cause, the 
eventual operational C6SS was 'to be installed at six different 
-commands in tl^e eastern naif of the United States, it also became a 
very important documenr^So^he. eventual users ^f the sj^stem as they 
correlated^data in their diverse existing files, to that which would 
be required for conversion to the standard system master file\ 
formats that woul5 be required by the operational CCSS. [ , . " 

In tha first design of the data element dictionary system, aJLl V 
canemonics^ssigned to 'data, elemefnt ^entries were l^imited to a maximum , 
of 15 character po,sition«. Through .experience, this was found to be 
'unsatisfactory, patticularly- when attempting toVreate meaningful 
programming mnemonics 'when doctmienfejfiag long names and attempting, to 
maintain a semblance of standard abbreviations within the mnemonic. 
In a subsequent redesign of the data element dictionary sys-tem, th(e ^ 
allowable length of a mnemonic was increased to 30 character -posi-<^ 
tions to match the full capability of the COBOL language. In .the 
CCSS, the maximum allowable length was increased to 24^ character ' • 
positions. Six positions were ^reserved to identify the file, sector 
.and segmefit as'a prefix to- the mnemonios which are used to identify 

data fields within hierarcliicallv structured master files of the . 
CCSS. Since the CCSS was to be programme<i in COBOL,' it was' recogn- 
ized that anj^important tool for managing the system would be the u • 
mnemonic 4>rogr^^ing tags that would be .usbd within 'the applicatior! 
program^ and would be used to describe the ^data fields within the 

..^CCSS master files. Because application programs written against | 
system master files* would te re'quirerd to use standard f ile. descrip-^ *: 
tions which were resident on the system libraries, a great degree of 
discipline was imposed on the application programmer 'as fie manipu- 
lated data within the master files or passed data to other applica- . 
tion, queues for use in .other systepi proces^fes. * Because^ the program-* 
ming mnemonic was to be embedded within the .applicatioii, programs and 
the master file descriptions*, and to a.^tertain^ degree reflect what 
was being manipulated within 'the syste'i^^^the mnemonic was made tlie ^. 
major key of the, data element dictionary: system', which in turji 

'dictated .that all mnemonics developed for entry into the data 
elfement dictionary data base must be unique. * ' • ' 
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The physical output format 'of the printed .DED^as remained fairly 
cotistant since its first 4)ublication . It contains an introductory 
chapter that explains the content of the dict£3Snary. Next is a key 
Word in Context (KWIC) index that contains all VtrdS used in the 
names assigned to the entries in the basic dictiqpary, listed * , 

alphabetically by the occurrence of all words /used in all the names." 
The KWIC and ex is used as the primary research tool vhen trying to 
determine if a data entry has already been defined ip the data base* 
Next is an alphabetically sequenced mnemonic index cross-referenced 
to the in-the-clear names that have been develope'd for the basic 
entries. The last section is th^ basic dictionary, sequenced 
alphabetically by, the names bf -the data element entries. For the 
* purpose of actually designing systems and for use as'^a functional 
definition reference, the sequence fot this section^as, in our 
experience, been found to be th«, most practical when seeking data 
defin^itions for either existing systems or for systems thkt are 
being designed. The format also allows for cross'-referencing 
related entries within the^ dictionary td show.hierarchal relation- 
ships. The ability to maintain these relationships is* designed into 
the system.^ » • * 

Early In the dictionary system development , 'a decision was made to 
allow other system design activities to register as users of pub- 
lished dictionary entries or, if necessary, develop, an^i become 
proponent for entries that had' not been previously entered. Thi^' 
requirement led to the development of the capability to accept ^n pufe ^ 
from multiple remote activities and ^ to register their interest *in 
entries to the dictionary, or to accept submitta;L of new entries, Also^ 
develdped was the capability to protect proponents of data . entries 
in the dictionary firoiT unauthorized update ^of this d^ta. This was 
'accomplished , in the edit pro(j^sses by developing system tables that 
crossrcKecked submitter input codes against entry prppeti^t identifica 
tions in the data base. - ' 

* * 
To control and document thej^ CCSS master files, a companion data base 

to the DED system^ was developed to act as*^ directory for the data 

that, was being stored in thei^yarious master files of ,the CCSS.^ This 

portion, of the, syst^ when fully developed was named the^Systems 

"Controraad Documentation (3YSCAD) syjstem. .By coupling the'TE*b da,ta 

bases, data element entries which were to be .in tfie CCSS master , 

files could be^ edited againsf the DED data bas^ to insure that 

mnemonics that 'were being used in the CCSS master files descriptions 

had beehf established and that the automated data processing field 

charac^teristics were compatible with the .BED entries. Since the * 

SYSCAD^.master file contained all the CCSS master file descriptions^ 

standa'rd C0&6iJ. copy descriptions in both COBOL F and ANS COBOL were 

geneirate'd and established 'on the systems libraries for mandatory use 

of the application programmers when accessing any CCSS master 'file. 

*. » ^ 
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Wellvin advance-of the installation of the CCSS, the eventual' users " 
had to know the structure and content: of the 'CCSS master files so ' 
that they could be,gin correlating data from .their system' files to , 
that vhtch would be required for the standard 'CCSS file structures 
and data content. The file guide publications produced by the ■ 
SYSCAD system were the primary d'ocvments used for' this purpose. 
Also provided the user from the SYSCAD syste'm/ for use as an auto- 
mated file conversion aid, were' magnetic tapes" that contained 
element by element descriptions of the master files foB use in 
automat^ conversion methodologies. These magnetic trapes also 
contained change indicators so that the user could be keiSt informea 
of any changes that might be occurring to ^e m'aster files. Also 
contained in the SYSCAD system are computed data ^sta^ting positions 
for all ■<lata fields .identified in the CCSS master fileand computer 
segment lengths for 'both fixed and variable length records. The 
descriptions also identify all data fields that are used as file 
keys. Operationally, lengtJh 'and key position infqrmat'ion is also 
used '{or keeping internal CCSS software control tables in synchron- • • 
izatlon. 

The CCSS in 'its present configuration contains 29 master files. For ^ 
' th^e most part, files that, were developed ,we«e designed to reflect' 
the data required .by the various functional logistics areas, taking ' 
into consideration the conseifvation of processing' time< effective 
use of storage devices, ea'se of data .maintenance and protectionof.dat 
integrity within, the system • These files in certain run conTfguta- 
.tions may stand alone or be coupled with other master filea to run ^ 
in a data sharing configuration. The. CCSS has one primary file- that 
contains common datd that may be used selectively ,or.. in copibinatlon^ 
by any functional process in the CCSS. All other "files may b^ ^ * 
influenced directly or indirectly by this file. The structure of 
these files is controlled and documented* through the use ot, the DED 
system and the SYSCAD systei. Since the first phase- of the CCSS 
became operational in April 1971, the CCSS has continued to be 
changed and enhaijced. .This, of course", has included changes to the ' 
master files structure and content under a concept -of scheduled 
system release management. In support of tt?e release management ' 
concept, the SYSCAD system is designed ^to maintain, control ani ' ' 
contain previous master^^e' str^|gp for regression test purposes, 
current file 'structures dnd futu?flfpie structures as they will be 
in projected releases of the systeml' J^ith the capability to manage 
► future file structure releases, standard file- description can be 
made available to the agplication programmer with sufficient lead 
®° ^^^^ system changes may be cocled and' tested for whatever . 
system release that* the changes are required.- This capability is 
very important because the^ magnitude, complexity and SQope,o£a « 
future systems, change may require that work> begin on *a systems 
change many'<nonths before it is actually fielded. 
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The DED and SYSCAD systems when coupled*, constitute a Data Diction- 
ary /Resource Directory which has the capability to record data field, 
descriptions, record th^ir use within multiple media and in the case 
of files, their location and interrelationships / - It, should be noted 
that the DED system may be operated in a stand-alone mode as a , 
dictionary with a limited directory capability. To exercise the 
control and documentation features of the SYSCAD s'ystem, it npust 'be 
^ coupled to the DED system, it may not stand alone. 

III. ADP RESOURCES " * ' ' 

" . ' V.' ■ . . . • 

A. Hardware Requirements * 

... . ^ ^ ^ 

'1. IBM Model 360-65 or better. 

2I 2314 disk unit or equivalent. Two required. 

/ 3. 2401-1 or equivalent 7-track tape- drive, 800 BPI, if * 

microfilm is to be .produced for Stfomberg-Carl«on 

microfilm (Optional) . . - ^ 

4. 2400-3 or equivalent 9-track tape jirive, 1600 BPI*. Five 
^required . ; - • 

5. ' 2501 card reader or equivalent. * 

6. 1403 printer or equivalent. , 
^7. Core -memory 'should be able to accommodate program sizes , 

up to 150K, and an IBM Operating System (OS) version 
21.8. 

B. Software Requirements 

*^ . * ^ , ^ * . 

* 

1. All programs 'are^ writ L*en -for ANS COBOL Version 3.1 
Compiler . ' , 

> ' 2^. IBM utility programs that are required' are: ' 

"a. JEBDG. • ' 

b. lEBISAM. ^ 
mGENR. 

lEHPROG.^ . ' . ' 
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CONTENTS 'AND PRODUCTS * . ^ . ^ . 

Everx entry in .-the DED data base contains ^unique -name that can be^ 
a^maxlminn length of 67 character positions. Each entry also contains 
a unique mnemonic which may be- a maximum of 24 characters positions 
and must be constr;ucted as a valid Common Busines^ Oriented Language 
(COBOL) programming mnemonic A 30 character position n^nenjonic may 
be entered with an override code. The do.cumen^tion and programming 
standards for the CCSS require that this mnemonic be used both when s 
documenting tKe system or within system application programs which 
use tlie COBOL language J Other required attrlbute]p of the data 
element entry are the characteristics of length, type and data field 
justification, the regulatory authority or reference for the entry, 
dat^ field data security, the date the entry was last changed', the 
identity of the entry proponent, the definition, in which cells and 
sub-cells the element is. used 'and if the element is locally derived, 
all of its data .codes and Items. Also pi^vided is the capability 
to register ottier known references to uses of the entry related 
to local publication ^efereric^s^ higher level regulatory references, 
reporc usages related "to Report Identification Number (RINs) ,^ Report 
Control Symbolsjv(RCSs) and jEorms usage. Application programs, file, 
usage, systems "usage references arid known synonym mnemonic /abbrevia- 
tions" may also be registered. Air of these ^refe'rences are available 
on automated cro^s-r)eference indexes for use *in "as-f l^^i^uired" inquiry, 

processes. , * 

•-^ * • * * 

...TKfe §.X^J&M>S contains information that describes the structure 
^lid datfalc^tent of controlled system data base master files, ilach 
data field Ir^^ the master file being described must use mnemonic abbrp- 
viations established bri the DED'data base, against which, the character- 
istics o^ ^length and data .type are edited. The file descriptor entries 

;also contain ^uoh Information as the .file acronym, record type, COBOL 
leve!^, decimal -positions, justification, key indicators, compiler to be 
use<^, occurrence or redef iilition information,, release number and 
information to ber'used for producing a file gtiMe publication. The, 
SYSCAD data, base will only update after data editing ha^ l5een success- 
ful against .^t^ DED data base. The SYSCAD data' base when updated 
produces system .master file COBOL Copy (both F and ANS) which \s then.y 
available for use by the application programmers, by whatever release 
version that is in work. File descriptions may also be prepared, which 
document jthe data content and structure of thfe file for documentation 
purposes^ The DED file structure attached to this repbrt is an example 
of a file guide description generated from the^'DEp/ SYSCAD systems. 
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The DED 'sjrstem contains 62 application modules. The system con8ist|^-<xf 
the following tables and files on disk: • . 



1 System: editing table (May contain a maximum of 99 tables 
within it) , ^ 

1 Master file containing — ^ 
1 data basi' control^'record 

6 data record types • > ^ 

J Cros^reference in'dexes (inverted lists) 

The files are Index Sequential/ BISAM orgdnizatipn which can be read or 
updated sequentially or randomLy. 

♦ « 

The SYSCAD system corftaiAs 41 application modules. Th$ system consists 
of the following tables and files: 

r , 2.' System Master file on tape. 

, 3 Master System Tables on disk. ^ 

A combination of tape^^^sequential and random disk processing is used in 
thi's system. The tape^file is processed sequentially with selected^ 
''records being read to. and updated oa disk. Tables are Index sequential, 
MSAM organization which^can be read or updated seqfientially^or randomly. 

' ^ » ' , ^ \ * , - 

The D^p System produces 34 reports which include foJsnatted and selected 
listings of t?he data base andx operational audit trail type reports. 

The SYSCAD System produces 23 reports which include formatted and 
.selected listings of the data base and operational autfit trail' type ' 
reports. * , 

The reports are fomatted using IBM Report Writer. 

Operational coNsiDBRATioNs 

Data for the update of the DED and SYSCAD data bases is controlled by 
ojie central activity. ; The DED input is received from any organization - 
within the Command that is designing,- programming or documenting 
automated systems. The input m,ay be^ created by either functional or 
AD)?! specialists. The SYSCAD data base is^ updated by computer special- 
ists whose function it is to control and document the system master 
files and' their ^standard file descriptions. - ^ 
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All input Is edited by system edit modules wfiich'do data field checks 
plus relational dat^ chalks prior to acceptance* for data base update. 
The DED data b^se is designed so that only proponents of an entry may 
update the basic attributes of an entry^ but other activities may 
register as users. After initial establishment of an entry, fixed 
field data 'may be updated independently. Both 'systems provide for 
periodic copying to tape in unload format .for possible backup f(^he 
recovery of the data. bases, ' . 

Both systems operate in batch mode for updating purposes. The DED data 
ba-SjB is updated morithly. The SYSCAD is updated on "as --required" 
basis. Inquiries into the DED' are.alsoMn* a batch, mode on an "as- 
required "basis . 

Both systems^ are used to control and document a large integrated 
wholesale Array logistics system known as the Commodity Command Standard 
System (CCSS) which includes^ocesses in the functional areas 'of 
Financial Management, Provisioning, Cataloging, Stock Control 'Inter- 
na*tional Logistics^ Equipment Maintenance,* Supply Management, and 
Procurement and Prociuction. ^ Other Command .systems data fields are also 
registered in the PEof ^ * 



VI. SECURITY 



Both systems are designed^ to document tgiclassif ied data descriptions. 
Provision is made in the DED to record the. security of the data that is 
being described\ Also provdd^ in the DED system i^the capability td ^ 
protect the basic integrity of*.a proponents data fiffld entry through 
the use of proponent tables. 

Since these systems do not deal with "people" related data, the privacy 
ac.t requirements have *not been designed into the systems. 
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* AID'S. DATA ELEMENTS' MANAGEMENJ SYSTEM 



!• Identification 



\ 



aid's Data Elements , Management System was. Implemented in AiU 
in July, 1974. This system, conmonly called DEMS, is designed 
£p »pro<iuce a dictionary/directory of. the data elements contained 
in the agency's information systems. The dictionary lists 
' ^ pertinent information about 'each data element, stich as, dat^ 

element title,' definition, COBOL name, types an& sizes, the, * ; 
programs, file§ and reports cgtitaining the data elements- and, in 
some instances, the manual fopns and reports where they appear. 

The pilot phase of fhis undertaking* was carried aiit* between July 
and SjBptember 1974. Based on experience gained durirtg the pilot 
phase,' the .system and procedures were evaluaterd and refined. 
Necessary revis^ion^ were mad^ to permit more efficient cdaing,' 
input, and analysis of data elemen'ts. As of December "31, 19=75, 
approximately 93% of all existing ADP systems *have beeh entered ^ 
into DEMS. . This represents in excess of 5,000 unique dara elenjents. 

Resppnsibility for the data. elements management program, the Data- 
Elements Management System (DEMS) , and the output dictionary is 
vested in the Of^ficS ^ Data Management, Information Management 
Division. Mr. Linwood Rhod^^s is the Chief of the Information-. 
Management Division and Mrs. Carolyn D. Moore has responsibility 
for the Agency program, ADP System and Dictionary. . She is also 
th.e contract monitor foj a tfeam of contractors responsible for , 
support, of the ADP systei^t. " - ' • » , 

For information contact: ■ , ' , > - 

Mrs. Carolyn' D. Moore ^ ' . ^" , - / 
Information- Management Division ^ ' 

Office of Data l^[anagement ' * 

Agency for International Development 
Washington, D. C. 20523 

Telephone: 202/632-0084 



II . Scope 



K • \ ' 

Scope and Objective - .The objective of the Data Elements Hanag^ent , 
^System was^tb produce a data elements dictionary/ directory 
that provides a foundation for effective management of data 
contained in ^information systems. The.^,(|ictfonary j^oduces ' . ' 
listings of data tailored to the needs various Clients 
throughout the' agency and ^provides "af^centralized location for 
all Jata, thus providing a b^is for "the evaluation essential to H _ 
data integrity. 
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111. ADP- Resources \ , . ^' 

* * ' «, 

~^ The data elements management system is installed on the IBM 360/65. 
Its requirements are 122K core storagS* All« data is recorded on. 
disk and converted to^tape. There is one permanent disk pack using 
temporary space ^an'ci one master disk. There are two outputs tapes and 
two tape drives. All files are recorded on backup tapes, and the 
system uses eleven (11) prpgrams of which six are edit progtams. 
The only software used is an internal utillt)^- sort . 

The system's eleven computer, programs are yritten^dn MS COBOL. 
The system operates Entirely in batch mode and update is;» maintained 
* ^ through punched cards."* The update schedule i'B irfegular. 

iV. Contents and Products ^ \ 

The; Data Elemen|^s Management systefa'^ primary report is the 
dictionary/directory report, which contains all the information" 
f in the master file apd occutrence files. Such data as d.e. 

title, definition., COBOL name, type and size, and all the ^ 
occurrences (programs, files, reports, systems) of the d.e* are 
listed. 'Several ^ther repoi^ts may tre obtained: 

" 1. A lifting of only the data elements and. definitions,, types - 
and sizes and COBOL names. (This is use^L wljen analysts 
are developing systems and need a shopping list ojg^^a^^'s 
available.) ' , J 

1 \ ^ ' 



2. A listing by program or file or report ID of ^ all 'the data 
elements used 'in that entity. (This too is a"h a^ialyst aid.) 

■•^ - • - . • ■■-.// 

3. A listing, by (manual) form number or^eport number of ^ 
.,all the data elements appearing on that fomj' .or report. (This 

is a .boon to reports/forms analyst.) 

4. A list in^^® system TD, of all the data elements in a 
given system. This is good for; management interests. 

5. A listing of a single datajelemfent identified with all the . 
occurrences.. (This i^ used tojevaluate the effect of changes.) 
Also, the syst^em produces bther miscellaneous reports, as required. 

' . . iij ' ^ , • ^ • 

' • Two data^ljl^s, the master file and the occurrence files are 
maintaij^Sm^ disk packs. The mast^t file has 500 characters'^ 
' ^ $0% "eat^^^^ord - the occurrence file has 102 characters for 



each re^^if. There are 'several thousand i;ecord^ in 6ach file. 
The file^^re in numerical sequence by data element code, 
however, %pe data elements may be sorted in alpha sequence. 

I . • \ 
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Presently, -there^'are. approxLmately 5,400 unique data elements 
in the system with an approximate total of 84,900 lines printed* y 
- The capacity of the 'system is unlimited.. 

V. Operational Considerations 

• ' . * 

^ " Analysts assigned to the maintenance of 'a system are notified 
, ^ when recording of the system's data^elements has been completed, 

^ ' and a report listing the elements and related information's 

. provided for the analyst's u^e." At that* point, maintenance on 

the date elements bf^ficially begins and the"^ Information Management 
' Division is notified in writing (Form 320-26) , whenever »data 
elements' in that system are revised, added or cancelled. The. 
participation of DM anal^ystj^ is vital to the maintenance of 
systems presently included in the data elements dictionary, 
^. • since a dat^ element revision, delation or cancellation in an 

ADP system greatly^af f ects DEMS. For example, if the "type" and, 
"size" of a data element are cha^nged^, ^then the information . - ' 

provided by DEMS, and' all the-files^, programs j reports and 
. ^ * • systems which -contain that data element in that .particular 

* application require revision. ' ^ . ' . 

*/ ' ' 

The information is collected^ op input forms after itv has been 
researched and' checked by the recorders. AID is presently 
using five data techn^^'a^is to record and maintain data contained 
in the -system. / • 

The data undergoes several inte.rnal checks before being processed. 
AID has achieved a^tw) percent error rate, which isT justified by 
the sheer volume -of the data. The errorsT that do ^occut usually . 
s. involve a mJLssp^lled word .or an onmiitted comma and do not 

affect the correctness of data contained about a data 
element ^ 

The edit program checks fpr- conformity of data but does not 
actually ^validate the data, backup files are/ maintained 'and ^ 
^punched cards are held for a reasonable length of t^ae. . 

However, it must be^ stated that a 'system is only as 'good as 
» its source documentatiion'. Occasionally, the system's- books 

or manuals from whioh data is extracted are Incomplete, \ ^ 
^ antiquated, or difficult to' piece together. • . * 

• ' , Retrieval of data i^ through batch mode using keypunch cards. 

VI. Security v ^ *^ * > . }y ^ 

Thei;e- is a gxeaS degree of inf ortpal control exercised by the . 
sys'tem's monitor. All input/output requests are routed through, 
> the monitor^ , Although the actual collection. ^ in machine runs) 
' .fs secjQred (limiteji official use), there is no fidhtrcW. of the 
^ data once distribution has been made. ^' ' 
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User Characteristics 



The data elements dictionary provides a logical starting point 
for Identification and evaluation of data for purpo^ses of data 
base management, conformance to Privacy Act requirements and 
security- of data. ^ vj ^ <^ 

DBMS provides SE^/DM analysts with ^ credible so'urce of ^informa- 
tion about data elements c6ntained in ADP systems documentation' 
as^ollows: ^ ^ _ 

(a) provides •PM analysts with an organized aggregat^ion 
of 'datji elements and related ig^formation; • 

(b) serves -as a catalogue to assist DM. analysts in identifying 
data already available when new systems are being developed. ' 

(c!*) provides for identification of areas affected when 
data elements are changed. 

(d) provides the basis, for usage, of data that^^^^/ acceptable 
throughout the agency, regardless of tbte application i 

thus promoting consistency and clarity in usage* 

(e) permits forms ^and' reports analysts to^mo^e effectively 

< identify and •control the data in agehdy information systems. ^ 

(f) '^provides a basis for forms and reports analysts to 
spot areas of redundancy and ^indeterminate data. 

DM' clients benefit from that portibn of the data elements 
dictionacy which\lists data elements' titles, definitions, % 
types anc^ sizes' and COBOL names , as this information promotes 
consistency and effective interchange of data among^ the 
users of ADP»*systems. The dictionary is written representation 
of " the dat\a processed by DM for agency'^use. t 

Because efjcectiye management of d^t^ is built entiMly on 
'ths^concept o'f '^standardization* bf data (and its use) strong 
emphasis is being placed in this area ♦ - ^ ^ 

Approxlmat^ely 75/^100 data elements >are -standardized and absolutely 
prescrjy^ed. for use. This effort was quite difficult due to the 
politics surro^'unding data. However ^progress •is ^being made. 
Several of our data elements are u§ed in^perchangeabiy among ^ 
3ys terns, and these data elements provide th^ foun&tionyfS out 
standardization efforts. 
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VIILr Cost . . 

, Costing information in the system,^ in terms of present resources 
can be obtained by- calling the project monitor. 1 

Cost feasibility in terms of long-range benefits or improvement 
In "management of data" has not been realistically determined. ' 
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DATA LABEL CONTROL SUBSYSTEM^ 

\ 

!• Identification . 

InJL972the U» S» Coast Guard developed- the ^ Data Label TCi^Jirol 
' Subsystem (DLCS). to aid ixi the development' and maintertance of the 
Joint Uniform Military Pay and Personnel Accounting- System (JUMPS)* 
System specifications, progi:am documentation, user procedures, and 
additional information , are available from: ' ' j • 



' Chi^, Information Systems Divsion (G-FIS/84) 
\ li. S. .Coast Gijard \' . \\\ 

^00 7th s^; w* ^ ' / 

; Washing toiv, D» Ct 20590 

Telephone: 202-426-1686 . . 



II» Scope 



The DLCS was, designed to act as a directory for the expected -285 
programs, 580 computer records, and approximately 2000 data elements 
needed for the JUMPS system • The system provided a means to verify 
* the^^rr^ct use of common^representations in the programs' '-to be- / 
writen ^"^^^^^^s providing a map of programs to be changed if an 
element or^'^H^^code structure changed • The DLCS also provided a 
chance to test the Data Base M^nag^ement S3?;stem (DBMS) to be u^ed in 
the JUMPS system • The systejn contained standardized names, field 
sizes, and other attributes of,,feach element • A manual definition 
book is maintained to fyrther define thdse* data elements found In 
th^ DLCS. 

III. ADP Resources 

The DLCS was developed using the CDt proprietary DBMS,- MAks-III on 
the CDC S300^ computer. Disk storage on one class "B" pacR-4..§iieeded 
♦ for* the three data files I Tape files are used for ^input and backup 
while output is to a printer. • 

A nuinber^f application programs were writteli to edit, updateV dimip, 
and restore thg file's/ These jobs rej^uire 40 to 90 quarter pages of 
' core consisting of '512^ 24-bit words* ' number of reports are 
produced using t^he MAR8-III inquiry language, QUERY. These jobs 
require, from 40 to 60 quarter' pages of core.. 
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Content and Product's ^ 

Data is organized into three MARS files, LABI, LAB2, and- LAB3 
located on a single alass "B" magnetic disk pack. Ch^acteristics 
of each data element are common to all three files ^nd^ appear in the 
"fixed length portion" in MARS terminology. The f ilfes are sequenced 
on. an arbitrarily ^signed sequence number (SONBRVfor each data"- 
element. Each file has one or more variable portions, each< of which 
consists^ of a variable number of fixed length areas. lABl contains 
non-standard COBOL abbreviations for each data element and. a list of 
programs using the data element. jLAB2 cpnta^ins lists of input 
forms.,. a?epdrtsi, filels, and^ record^ in which fche^**da£a e:l^ent' appeals . 
Transaction codes -atid ass6ci4T:ed function cc/des are^coVtain^d on ^ 
LAB3 for 6ach data element. 

Standard reports include an update and exception .report for* each 
file .as it isT^ updated. ''Reports of data element characteristics' and 
usage 'are produced through the use of the.inquiry language. Special 
inquiries are run pn an as required basis. «^ 

Operational Con^j-deration ; 

Data is to be prepared by the systems analyst during the analysis 
and design phases of the new system development. Coding sheetilin 
the necessary record formats a^e pre-printed. After keypunching, 
jobs are submitted in batch mode, to update the- file and produce 
standard * reports. Backup dumps are taken on a regular schedule. 

The data is minimally edited before update and errors 'encoun4;ered 
•are listed on an exception repprt.. Corrections are made by resub- ' ' 
mitting the input forms. * . * . 

A special means of updating the fil^ andc record lists is provided 1)y' 
one o:^the programs. This' program reads file descriptions and 
record descriptions from a COBOL program, validates the COBOL nameg 
and^. update^s the ^corresponding lists for that element. 
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. VI. Security / - 

* , • * 

•Users of the Data Label Control Subsystem must identify themselves 
to the Multiple Xccess Retrieval System (MARS) whiph processes the 
DLCS. User identification and passwords are both required for 
access to MARS, which is operated on the CDC 3300 , computer system. 
* ' However, there is no individual data element 'protection built into . 
the DLCS, although the capability, exists. Users jpf the system must 
rely on proper user identification and passwords^ to protect access 

' ; Data security/ is further controlled by/ access lists of^ personnel 

authorized, tc^ proces/s jprograms on jthe [comppter system.. If ai^rson 
submits a job without the proper authoifization to run^ that program^ 
the job will be' aborted. • 

VII. User Characteristics ' 

The DLCS is used by technical personneJ^ computer systems analysts 
and computer programmers) . In ^dditibn, non- technical (user-) 
personnel are involved with defining data element characteristics. 

■ The DLCS coordinator reviews and submts updates on an as required 
basis; Inquiries are prepared by the person desiring the material 
and submitted directly to the Transportation Com.puter Center, 

' TCC. ^ ' 

VZII. Costs ' ' . ^ ' 

* ' ' ' • • 

The DLCS was developed by five persons in 1971 and 1972. The skills 
emplo/ed were those of computer system analysts and computer phro- 
gramiers. The total development time' was approximately 24 months 
^^ath an estimated cost of $30,500. 
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^ Department of Motor Vehicles Data Element Dictionary 
State of New York Department pf Motor Vehicles 
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. , STATE OF JIEW YORK 

DEPARTMENT OF MOTOR VEHICLES * - 

Data Element Directory ' (DMV/DED) ' ^ 

!• Identification 

•The l^ew York State Department of Motor Vehicles is developing a 
Data- Element Directory (DMV/DED) of its computerized files^» The 
Data Standards and Control Bureau of the Division of Data Admin- 
istration is^ responsiblej for producing and maintaining, the directory* 

For information, contact: - 

New York State Department of Motor Vehicles 
Division of Data Administration 
•Entire State Plaza 
Albany, New York 12228 . 



Attention: Warren Crow 
Telephone : 518/474-6871 



The scheduled completicfn data for the directory ia July 1977* 
II* Scope , ' " 



The Division of Data Administration was. organized in 1972 to' 
coordinate the nnanagem^nt and protection of the Department's 
data resources* The Data Standards and Control Bureau of the ' ' 
Data Administration Division wa$ directed in 1974 to develop 
and maintain a Department of Motor Vehicles Data Blement Directory* 
The directory is intended to bg? a central data reference guide. It 
will be used to standardize data-in the Department of Motor Vehicles 
thereby promoting, data interchange among organizations involved in 
^ traffic safety. ' * • 

\ ■ • ■ ' . ■ • • 

Since the bulk- of the DMV/DED contains definition information it^ 
is •basically classified as a dictionary although it does contain 
some characteristics of ^ directory* The 4ata elements are linked 
to records, files, trans3.'Ctions and their input, file and output / 
representations are documented.^ ^ ' * ^ 

III. APP Resources • ^ , • ^ 

, V - . ' • ' . /■ ■ 

The DMV/DED is not dutomated. . ' • 

'IV. Contents and Products 

The D^/D^ contains three categories of information: identification, 
defin±tion>aa;id .representatJion. Identification information furnishes 
the data elemeittv^ith unique labels and links the elements to records, 

IC ■ I ^[^ • ' '7^'"' DMV/PED 
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files and transactions. Definition ihforaatior/explains the * 
content, purpose*, source and use of the data ^element . Repre-- 
sentation information describes the lengthy 4:jl)e and format of 
the data item^ There are five sections to^ the DMV/DED: - 

a} Explanatory Text 

b) Data Element Description 

p) Files Inventory 

d) Transactions Inventory 

I ' * j V^'^f Reference h 

A. The Explanatory Text describes the purpose, content, 
' ^ scope and use of' the directory* 

Data Element Description. This is the core of the 
, ' DMV/DED. Descriptions are listed alphabetically by data 
element signature. Eadh data element description 
contains "the folloving. \ 

1* Signaturejr^ the complete unique name of the data 
^meri^. . , 
^Code - a four position alpha numeric code 
assigned to the data element for use in manipulating 
dal 

^ Name-vin-context - description of how the ^ignature 
appears on forms where uniqueness is provided by. 
.context.* (e.g., the data element "name, licensee" 
appears as "name" on the license certificate.) 
4. Abbreviation -the shortened form of the signature 

as used on reports and forms. 
5* Techhical definition - explanation of the content 

and purpose of the data element. 
6* Input source - identification af the originator o*f 
the data, element"!* I 

7. Use - explanation of the general uses of the data 
element . , / 

8. Special EDP use -r description of th^^data' el^^jentfe 
use for specif ic data processing purposes, (e.g., 
access key, sorting field). # • ^ , 

9^. Synonyms - words similar or identical in meaning to 
the signature. 
10*. Computer, files - list of files ^lere the data|^ 
^element appears. 

11. Transactions - list of. transactions ,where>' 
element appears. 

12. Systems - li>st of sets of computer pro6^sses where 
the 4sta element is used. 
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13. Components of a composite data element - if a dat4 
element consists of two or more other,data elements 

^t .is referred to as a composite data element. The* 
data elements that make a composite are referred to ^ 
as components. For ^example date of birth" is a* 
compos'ite data eiejrfent whose /components are "year", 

."month" and "day';< 

Traffic Records reference - signature of the data 
element as it appears in the New York State Traffic 
Records Data Dictionary. j t 
NHTSA jfef^rence - name and f reference codes c^f the 
"data element as it appears i in the National Highway 
Traffic Safety Administration's Design Manual for a' State 
Traffic Records System . i / ^ 

16. t^omments - information that does not fit into any 
other category. 

17. Representations » 



14. 



15. 



a. Level - input, output, or file representation. 
bf^ Type — name, abbrevfStion, code or numeric 
value. V. 

c. Length - jumper of positions or bytes. 

d. Format - 'alphabetic, numeric, etc. * ^ ^ 
•e. Data item description - described and illustrates 

the possible values of the data element. 



D. Transac 



tions inventory. For each transac triSTf the 



following information is given: 



Transaction name. , ' " 

Description - a brief narrative ^ the purpose of 
the transac t ion . 

System - ^^j^t of systems where the tran^saction is 

Data elements. A list of data elements* that appear 
in the transaction. . \ ^ 



Word reference. Words in the DMV/DED are defined as 
signatures, names- in-context, abbreviations, synonymSj^^ 
and components of composite dat^ elements. All woi;4s 
^re, listed '^lphabeticaily4^in the word reference and 
linked to data element sigjp^tures. This was created to * 
Kelp usetsMpcate a' parti^lar data element description 
without kT^bwang the full signature. 



Operatfional Considerations 



Our main source,, of data was system design documentation. Where the 
documentation was, missing or inconipl^te, interviews with the ana- 
lysts and programmers and some users provided the necessary infor- 
mation. 
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Oir^ data collect ion^tool is a form designed by our bjureau based upon 
material developed Iby the^NSI Data Directory Committee (D-20.1), an 
eutgrowth of tfhe ANSI St^e Model Motorist D^ta Base Committee 
(D-20). All data element desStiptions are to b.e ^cleared by pertinent 
analysts, programmers ^and users. . . 



VI. Security ^ * 

Some confidential restricted infoAiatiorj such as personnel file 
transactions has been omitted from the directory but there are no 
] plans for security restraints of the d'ii^ectory itself 
i i ' ' ' .. 1 ^ , V 

J \ ' . 

VII. User Characteristics 

, ^ —2^ 

The anticipated heavy users are systems analysts, progr^ammers and 
Data Standards and Control Bureau analysts. We also anticipate 
usage by DP Management, some users and ^ other organizations involved 
. in traffic safety. * ' - * ^ 
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Federal Power Coinmission Regulatory ^Information System 
. ^ , 0 Federal Power Commission 

#• ' * 

, ^ ^ FPCRIS, 
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FEDERAL POWER COMMISSION 
REGULATORY INFORMATION 'SYSTEM, 
"DATA ELEMENT DIRECTORY . 



IDENtlTI^ATION 



The, Federal Power Cqfnmission, Office of Regulatory Information 
Systems, Da-fea--Management Branch, directed the development of the 
Data Element Directory as an ordered cpllection o^ data elements 
data items, source, usage and output references, and~ other inter- 
relationships to support its Regulatory Information ^System (RIS) . 

For information con-tact; 

FEDERAL POWER COMMISSION \ , 
Office of Regulatory Information System 
825 N. Capitol St. N. E,. \. - ^ 

Washington, d/C. 20426 

ATTENTION: John H. Yienger ^ ^ 
PHONE iL 202-275-4935 ^ * 

FPC's Regulatory Information System ^nd its associated Data Element 

Directory are currentlf^, under development. Derailed documentation is 
thereby not available at this time*. 

SCOP<g ■ ' ' 



The Data Element Directory (I)ED)^s a software-user tool through 
which the RlS^d^ta bank is managed. In addition to information ^ 
; necessary to describe data b^ses, data elements .a'fid data itremT, the 
DED has control' information nece;ssary tp'^Tomp5ete|y direct' the 
operation of the generalized sof twgj?6nepessary to 'acquire, edit, ♦ 
audit, manipulate and administer all the data bases of the RlS ^data 
bank.y^The DED performs the functions of a directory and a diction- 
ary. / In essence the DED is a data resource repository vfor* the 
RIS. • ' 



ADP RESOURCES - ■ " ' - ; 

^ /!. 

?he DED is installefl as'a system 2000 (S2K) data^ base on the IBM 
70/158 operating under MVS, Other than the standard overhead, tfie 
DED^Mk over 6 million characters* of data. The DED can be processed 
intiQ^actively using System 2000 natural language t)r in batch mode 
using ANSI COBO£ with System 5QO0 Programming -Language Interface 

(pn)- _ ^ . 
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CONTENTS AND PRODUCTS ^ * | • • 

The DED is a System 2fK)0 Data Base 'itself and is essentially a three 
limbed tree. One limb is for the Data Bases of the RIS", in which ^ 
the Data E16«entsare defined and cross-referenced iri' dnpu^ documents , ' 
data item iistsT^« uhits-of-measuire. Also the^ta element 'js' input 
usage and output^requirements relative to edits Audits and reports • 
are spfecifi^d. ^The seco^ limb of the DED is the data'<tfan lists 
for the appropriate datajjelements. Each data item list described 
^d fetanrfardized by name, code and%abbreviation. All*the data il;em ^ 
lists form a'data register. The third l±mh of ,the DED is a list 'of 
the appropriate source documents -which are the collection media 
employed to collect data^. The title? of the fields on ttfese schedules 
are the data elements . * ^ . ^ 

* 

OPERATIONAL CONSIDERATIONS . * h , ^ * / 

The Regulatory Information System and its associated Data Elem'ent 
'Directory have been developed concurrently by the Federal Power 
, Commission an4 its contractor, Planning Research Corporation. All 

data elements, data item lists, data 'bases and Forms/ Schedules* 
/source documents) are a product of an integrated development . 

effort. 

. f ' . • 

There is a unique set of source documents used Xo supply all the 
d'ata required by the Data Element Directory. The'se input documents 
are prepared by Data. Base Administrator^, D^a Standards Analysts, and 
Forms Designers. " These documents collect Jail the definitions, 
characteristics, and interrelationships data corttainea in the,;, DED. ' 
'This data is ^coordinated and processed by the Data Base Adminifs- 
trator for .tlie Dkta Element DireetoryV 

idl initi^ loading and updating of the DED are performed in batfch 
mode for y^udit and control purpose, usually overnight. However, the 
DED is maintained on-litie and is available. for interactive quelries 
and j)riftt-outs to support special analyses. No data base changes, ^-^ 
to ^itrfier the DED or the other RIS data bases' are performed inter- 
actively. Und^ the direction of the DED approximately 2 billion .^ 
characters of RIS data ate collected, edited, audited^ apprbved and 
maintained on-line for: any 3-year .peryoxi . The data are massaged for* 
analysis via the constraints of the DED. 'This includes the DED's 
role as being the repository to define fhe^parameters and bther 
control information, employed by the software to maintain thes^^llIS. 
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SECURITY 



Security; for the RIS and 'its DED* are imposed for the pSfbtection of 

the data within its environment* against accidental, passive and 

willful destruction* or abuse. Presently, the security features are 

those provided by the^BM MVS operating system and system^ 2000 data 

base m'koagement system. ,These incL(i3e several modes^ of password 

protec^'n.* of the data. 'However, pEC's security program is contin- 
^ , f • j • » « ' 

u^ly under review. * * ^ . *^ ' ' 

USER CHARACTERISTICS ; * " 

The DED. is developed, ma!intained and. operated by the^ Data Base 
Administration group. This group is responsible for' all data hases 
cOf the RIS and is in constant contact with users. Through this contract 
they are familiar with User requirements ,* res^qnsible for RIS .da t^.^-^ 
base and i^outc'e document design, and, load, update and maintain the , ^ 
« RIS --data based. ' } -f ^ . \ 

The primary users of DED are the Dafi9*Base Administrators. They use 
.the basic reference'and cross-reference'' features of the DED when 
designing data bases and sodrce documents and in evaluating request- ^ 
ed modifications or enhancements. In additon, the DED is used to. 
define the 4ata elements and their prescribed data items f^r filling 
^out^sT)urce documents. * - 

CONCLUSION ' ^ ■ ' 

The DED of the FPjC's RIS' is a highly specialized data resource, 
manager tailored s^if ically -for FPC's generalized dat^ base ' 
software process.ing -sysJl^em. The DEJ), is a System 2000 'data b'ase , 
itsePf^and is processed and maintaine%by, the same generalized-, 
software system as all other RIS data ba^es. ^ese^ fab^rs must be 
thoroughly inv*estigated when considering the possible use of the ' * 
FPC'^ DED. ' 4^ . • ' • * . 

/ 

f , 4 , 
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IDENTIFICATION 

Office of Prime Resoonsibf 





'The Department of D^e'fense Logistics Data Resource 
Management System (DoD LOGDRMS) was developed by th-e' DoD 
Logistics .Data Element Standardization and*« Management Office 
(DoD LOGDESMO) to sifpport execution of the Department of' 
Defense Logistics Data Element Standardization and Management 
Prog-ram (DoD* LOGITESMAP) . For l^nformation on^jthis system contact:. 

Chief" * ^ . 

DoD Logistics Data Element Standardization 
^nd Management Office (LOGDEShfb) 

Attention: Mr. A. HocTiman ^ , * 

Room >S 69, Hoffman Building 2 ^ 
/ 200 ^StovaLl St:;,reet . . * • ' 

^' Alexandria, Virginia 22332, ^ . 

Telephones aire: AUTOVON - 221-932^ or^ - ' 
, . \ > ' ^ < ' Commercial -'(202^ 325-9324 . 

Documentation ' , * • • 

System documentation is internally developed and' 
maintained. A^procedures manual for >the DoD LOGDESMAP has 
been compiled and *is currently being coordinated throughout 

^ the Department of Defense prior to final approval, publi- ' 
cation, and implementation. Additionally, a users manual is 
bein^ compiled ^as a companion document to the procedures « 

'manual, Koth documents are proj'ected for' issuance by . 
June 1977. ' , , * ' . . \ ' ' 

-SCOPE • . ' • * 

Reason for Implementation ' ' J* * * , 

\ .* *' The Det)artment' of Defense (IJpD) Logistics D^ta 
Resource Management System ^(LOGDRMS)' was develojied to proVid 
a more ef f ect;ive^i vehicle^f or the me'aningf ul -.standardizat ion \ 
and management of 'datta employed within the DdD logistics 
community. * 

\ , ^ * LOGDlfcMS specifically, is , designed to pro^idet 

Uniform identification^' categorization, and 
classification of the Sata emplbyed in DoD 'logistics 
data -systems ♦ . ** / ^* k . ' 

■■ v"'"'- ■■■■■ ■■ ' ■ ■ - ■ 
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SCOPE. -(ContM) 



** An organized means for family, gr^i^ing 5f 
related data* representations and subjecting such 
groupings to the formal processes of, standardization, ^ 
i.e., simplification and the development^, coordination, 
and, publication of standards* 

** 'A vehicle for storing, displaying and/or publish- 
ing standards to personnel 'engaged in data system 
management, development, dyesign,' Operation,-^ maintpnance^, 
or use iii' afder to maximize reut ilizat ion. of existing 
data as opposed to time consuming and costly generation 
of. new data . , ♦ . • v ' , 

** Necessary infotmatfoh supjjprt services to manage-* 
ment and operating elements so as to maximize their 
visil)ility existing data and inf ot'mation and thus- 
ef fecf ively'llmprpv^ their decision^maki^ng , processes % ^ 

** An analytical tool fo-r. recording the hierarchical 
relktionsjilp? of, data to ' the. en t ities of vhich they are 
a member c( e . g . , forms, reports, files', etc.) and to tlie^ 
entities into which t-h^y logically subdivide ( e . g • , data 
elements, d'ata chains, data codes, etc.) which- can be 
utilized to -assess the impacts of planned or proposed 
data^ system changes or iti conductin^g required analyses. . 

I ' ** Cri£icaily needed management* o^f logistics data as 
a "|resource^^' in a .manner similar to that, employed * in _the 
management of*oth,^r resoirrces sucK as materiel, personnel, 
facilities, money, etc*. 



Background 



* Departn^ent of Defense (DoD)' Directive 5000.27, 
"Logistics Data Element Standardization and: Management Program 
(LOGDE^MAP)", dated March 28 ls975 - ( a) establishes, defines^ 
the.ob j ectives of , and assigns responsibility for the DoD 
LOGDESMAP; (b) establishes and 'defines b,asic principled ^nd 
policies, for the management 'of lo,girtics U'ata within the DoD; 
and (c) -authorizes pjibj.ica tlon of a LOGDESMAP Operating. . 
Manual prescribing uniform p^rocedures to he, applied by 
participating DoD Compon,ent&. ^ ' ^ - 

* PoD Directive' 5000. 27 ^identifies the object iyes of *the 
DoD. LOGDESMAP as follows':. ^ ^ , 



SCO^E (Cont'd) . ■ • . < " 

** - Improve the management *^of DoD • resources at eAtery • 
level througl) the reduction .of unnecessary overlap and 
duplication in DolJ logistics data systems. • ' 

** Reduce the -cpsts of DoD data systems design, 
^ development programming ' and .operat-ion. • 

** Assure the effective ^management of logistics data . 
bases. . • ? ^ • ' ■ 

** Faciiitate the interface and integration of/ 
logistics data systems and the interchange of 'data T>etween 
and among such systems. - . • , 

\ ^ ** Provide ^ common base- of standard data elements 

afcd related features fo^r Use throughout the DoD lo.gistic^ 
:^pOTimunit^ as well as other affected. DoD communities. 

« # ' 
- , Permit more efficient -determination of the impact^ 

•of anticipated, proposed, and/or approved changes by 
thosa*oi?ganizational elements planning-, administering,^ 
and .-operating ' programs and< systems employing logistics, 
data\ ' " • ^ ' ' 

^ ^ The following policies 'are enunciated "in DoD Directive 
5000.27: , ■ , ■ , • 

• • » * 

**» ^DoD Com'ponents will jointly develop uniform 
methods, proceduires, and controls for ,the management of 
DoD "logistics data bases. 

• » ^ * -I 
** . Management.' of logistics data- on a system oriented 

^ \bas_l8 (i.e., how data ,a.re used as' opposed what data are) 

will continue to be accomi)lished. by the organizations 

responsible for logistics data sysjfem development .and 

• conf igurat ion ^manag^Jfcfment . ' . ' . v* ' ' 

' : ' ■ ' ■ * . ^ ^"^ " •* 

** , D^oJ) standard data element's and related f enures 
will be .developed $hd used* unless specifically exenrpte'd 
. • by the 'i^ssistant Secretary of Def'ense /Ins^tallat ions and 
Logistics) ASD(I&L) In (a) the d'ev^lo:ptaent or re,design.. 
of automated logistics systems 'and (b) "authoritative^ 
, issu^i^es . which pr'escribe the collection, reporti|ig, or 
interchange- of logistic? data. • 

• = * ■' ^ .72 . ' • ■ LOGDRMS 



SCOPE (ContM) • ^ • • 

*** 

^ Issuan,ces of a joint nature ' involving ijequlre- 

^ ments for the development. Identification, or Interchange 
^ of logistics data will' be coordinated -under ttxe provisions 
of the DjdD LOGDESMAP. ' , • , 

, Applicability • * ' . • 

Tlie Dt)D LOGDESMAP applies to all DoD Component 
organizations In.volved in (a) . the deveX/6pment , design, or 
i^fcpdlf ication of automated logistlcfs data systems; and (1?) the * 
initiation, coordlna tlon ^ publjLcatloi>, or revision'' of ^ 
.>Kithoritative issud:nces which require the collection, repo'rt- 
-ing, or . interchange, of logistics data, ' ^ ""S^ 

' * For the purpose of this program, the area of logistics 
encomj)asses all responsibili tiejs assigned .to. 'the Assistant 
Secretary of Defense (Installations and Logistics) ASp(I&L)., 

History ^ , • ^ • ^ ^ 

The improvement of DoD logistics 'systems has necessarily 
beem aiosely related^to th*e emergence and* advl^tces ^n the 
tecKnology df automated data -processing and improved communi- 
cations., As 'technology has progressed, the development 
of automated -logistics systems has 'moved with varying degrees . 
of speed and has been hard-pressed to keep pace. In part* this 
h^s bee'n.due to the inability to 'capitalize "up'on existing\i 
technology; more importantly.it is .t?he .result of long .leM 
time necessary for effecting system changes. , kh component . , 
s'ystems become progressively complex, these lead times have 
become increasingLy prolonge.d. The final product is a 
series of subsystems or pj;ocess6s, each nniquely complex and 
'difficult to change.-^ \ ^ ' - 

- * Th4.s ^experience hi^hligtffed a» critical oeed* for a , 
master .Tplan aimed at preVenting the/pf olif eratlon o^ non- I 
standard, incompatible,* non-comparablei -ari(& 'independently 1 
develoJ>ed systems'. Sucji ^a plan, identified as 'theyDoD* >• 
Logistics Systems Blueprint was promulgated in .196« atld 
implemented in^l972 as the* Department oi Defense Logistics' 
Systems P.Ian (TLOGPLAN) . . • v 

^' ' • ' ' / ' ' ^ . * 

• . . A^yital .part of the Bluepriat addressing the^ standard- 
ization, and management of logistics Hata was implemented^\in ' 
. /1970. through initiation pf the program ^iltimately form|j3Clzed 
KyDoDTDirectiv-^ -51)00.27 ( ref erenq/fe- para . IIB) . ^ 'r^: 
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II. — rcOPE .(dbnt'd). ' • ■ 

* * 'The B-lue^rint ^por.tUoTi"dealing/with I'ogis-ticfs d-si^t'a 
pointed out that the^rap.id ^^oliferation^ of- 'logistics . data:" ^ 
language vocabular-y variation r(e3u];ting f jrpin ^ndepe^ndent 
system development action^ in today ''.s .highly i-ntejr^iependent ^ 
logistics fenvironment seriously liamper.^ .e^f.e'ctive^ ace o:m.p fish- 
ment of logistics i\iTi(^t^op,dLX 'ai±spion%y'^^^rj:i(^ . . 

overall DoD* point of view. As a* cansequ;^nce,^ e^^^ ^eflating^ -J. 
'data sys-tem must maintain a- >ull't--in' cap^a^ilityV^or.^ , 
lating the data language vo c^abiflaryl of d t;iie'r d'at;a .sysji^eii's wit%^ ' 
whfch it 'interfa'ces Im- order- to jDiyerVome'. tT^ls coitt:inuirig 
.trend, it 'is intended that ,*maria^ete*4ttt -dilsp^ ./-'u " 

applied to data and information in avirf-aniier\&^mUi^ tl^ait . 

emp^loyed in the management of .materiel/* fiata ^aad . iir'f ortira'tiqtiV- 7" 
.j like materiel, are susceptible tb^'the' fulT range of ibgfstics ^ 
j life oytle ' functions' (e..g^. , -r.eq^ulr^ments dejiejrmin'at ion.;: 
identification;^ standardi'zatibnY a9"^"i.^i.?^o^> stt^rage; - ' 
distributioji; ut'^li^zat ionr'^dispSJ'ski)-^ ^ "V^- ' • •t^ 

* E r 1 y efforts bVl^O Gi) ES ^t)^^ V e rje /m a pu;al , - 'fol 1 oyed b y^. ;.f ' ' ' y^i':- 
a computerized syst'em *in batcl|^roc*e|^^ng,^pio(][^^^ CQjistideftlTng* ^.{.^f 
the enormous 'valum.e of recqriis .and, *the .e'xt en'^ive ^fe^^ 
to update and publish i^hfoVmatioii.,.- -a^.m^or '~jgf f.^^ to.j^^ ^/ t 



As a part of 
As socia-tion Sys^tem 
While it was cone loaded, .tha t. .^S 
ment over the can$tj:aii;^^d 
requir ed^ improvemen t& 

* compxehens Iv e ^ sy.s teia ^fuhct ipifkl r equ i^mfent. ..wjrfs' dj^y eito^eci • ^ 
Based upon this requirement',' 3 • ^^^r v- . ^ or 

Computer Cor p.o .rat ion ojf 
package) on' a 'lease.;bF^'s isv? 
to use the l^easet 
tj.me shar ing>4)asis , 




Id s"of tya.re. oii t*ha£/ Ag^t^cy.'^^v.cc^^ v.* 

► Is. I'K . 'r*^' •* — i ^- . ' 



* . Mor^ re\:ently, all ac-g xriL s^i^ti'd n; a^<|t i b^n^< t a,;*6 ecdfe ai 
: software package (DBMS) fcapab lev^£\ti^q-^ilag.^^ 

ments as well as o ther ♦cu.rrent pxo^j^t^^,\}^^ rf|)i<ul/ir.eme]i::ts ^ V^J 
* was undertaken ]>y . trfS^ ^De^,^nse\ A^?e.n^^^'''(>DI^^ t ^ 

'such "acquis'i t-ion " is .comp^l^ted>' i^-ls »pi'aiih.^TL^^^ 

, the lease agreement* wi^lf' 'the .Dap;aftji.e^^ a^'d ^o'. . JP* 

L * c P riTTi TMTt-oT" JlnPaf-loH at'^^n a.Vnii t- rttW 51 t-'a f- 4 -r\*ri \ ^ 1 e'X and VjL 3. 



employ' DLA!s computer iocatfed at.^ C.aiiero>n* &jtatij<)*^,\^le': 

Virginia ;^ V, - •' 4!^'-:j^-^' (J}^^'-: - .^l 

\ ■ "-r. ^'V t;- 



I 



' * - • 4 



as 





' ^ Implementat Ion Level ^ y 

LQGDRMS ■ is a Depiartment o£ Defense-wide- system 
isofar as content is concerned/ 



The* system currently operates a.t three physical 



es« 



5c- 



^ ^ ** ^ DoD LOGDESMO Updates (both crSte and change). • ' 

are entered, using data teriuinals. Qu^ry is conducted 
on *a plama^ed or.axf Jaoc ba^is with priirt .out , {optional on 
desk top line printers. ' 

** • Defense Administrative Suppott Center (DASC) - 
DASC (a field grganizatioiff^ of the Defense Logistics Agency) 
provides programming* o.f "segments" and testing and. debugging 
using a tes'£ base. When approved, segments are entered 
< in LOGUrMS datg base iov use by LOGDESMO personnel. All 
efforts of* this nat;ui;e are performed onrline using data 
terminals. ..DASC #alst) provides bat ch processing ' services 
.""using magnetic tapes 'dumped^ from, the physical' data -base. 
DASC also a^rranges^ for micromatibn suppor,t services to 
^ 'develop mictofiche' of LOGDESMAP .publications derived from 

bkt ch^ pr6cess^d magnet ic^-^teape erftered into Computer Output 
-^-^.Microf ilm (COM) equipmeiitN 

' X * * . • ' ' ' ' ' ' ' ' ' " ^ - 

.** PXpar-t-ment of' Commerce , Washington, Jt is the < 
.owner of^ the Model 204 software and the^pmputer employed 
*, , ^*for;L0-6DRMS . \ The physical Tiles of LOGDRMS ^re stored at 
Commerce on a ''disk ^iack. 



^ ' Follow-on. pla^rinlng provides for the terminatiott ^jf the 

Department of Commerce lease arr^angemen t* with the DASC 
^ assumipg^ all res*ponslbdftLties formerly peyfd'rmed b^. Commerce. 

^ • J .• f ... 

^ ^ Additional long range ^planaing provides for .imil'tiple 

'update and. que'ry, si^s to be lojcated^at various ;syst©m design 
centers throughout Ae United States.' • * 

111. AtiP RES-OURCis * , ' . ' .. 

. / Hardware ..Requirements • . ^ , \ ^ ; ^ * * . - '\ 




* IBM Model ,360-65 (Departme*nt of Commerce) 



"*• One '(fr)^aisk pack , . i \ J. . - . ' 1 

t O.he . (^). Jline printer" \ ■ . . {, .. ' 

Five (5) (iata terminals ' * ' > • ^' 



' ** One at" DASC • . • : ^ 

ERIC. . r ■ ^ 
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III,^x ADP RESOURCES ' ' ^ 

V ** Fouf at LOGDESMO % ^ 

d ^ *^ Four (4) desk top line -^pr inters ™ 

' - s ** -One at^ DASC 

• ^hferee at LOGDESMO-^ „ . ' 

* One (1) card printer • ^ * , 

' \ * Batch Processing Hardware IBM 370-155 involving 20 
magnetic fapes. ' • • 1. ^ • 



. Software Requirements^ 

* Computer Corporation of America Model 20^ Data *Bas e 
Management System (Department of Conme^r ce)^ 

* Program segments written in Model' 204^ User language 

* Batch processing programs ar^ written^in ANSI COBOL 
IV, CONTENTS AND PR'ODUCTS * ' - , ' 



Data Organization 



* .... 



D^ta Bases ; The LO'G.DRMS data ba^nk ^cansists of 25 
data bases including one for^ 

1» a. Each Department of^Defense Component 

• b'. Other Federal Agencies (U • S . • Goyeriment) ^ 



c . ylnteijagency /Gro^ups/ Committers 



C» /J. nu e JL^cig eii cy /^j rt^ps A u omiui t u eeti - | 

d • |*'Non-g6vernmen t Ofgaiiiza t'ions . ^ 



\e, S tate/Local Government Organtz^atlons V * • 

f. Inte;:national Government. Organl^za't ipns 

. . « ^ , ' • ' . ^ ^ ^ ^ ^ 

g» DbD LOlGDESMO * * ^ * . ' ^ . . . 

' * Sectors; Eiach 'data base subdivides ±^to sectors as 
follows; • < '\ " ' 

' a, Organizajtipns 

b 'Functions* 




IV. . CONTENTS AND PRODUCTS 'CContMV 



r 



ERIC 



^ c. Subject Matter 



d . Issuances/Publications. 

e. Management Plans 

f . Management Programs 

g. Management Stud±-es 
. Management Systems 

1. Managemeiit Subsystems 
j\ ' Managemeirr j2^perations 

k. Management- Pro cedures 



J 



1. Automated Data Processing Systems^^^ 

m. Automated Data Systems ( Appllca'tlo ns) 

n. Data Syst ems (Processes) 

o. Automat ed ^^^gram^s . ^ 

p. Data Fil e^^^a s e s * 



Records-/ Segments 



•Farmats 



s . . Forma^ -v ! * 

t.| Documents (Inp^it) 

u. 'Reports (Output) 

v\ Data Fields/Blocks. ^-^ ^ 

W. Data^ Element A'pplications ^ 

X. Data Chains* ' 



y.^ O'liher Multiple ^Data glement/ Re pre^'enta tlves 



'z. Data "Elemen't Categor^^s 
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IV. 




CONTENTS \ AND PRODUCX^ 



nt-'d) 




A/' 



pk-k 



Data EMement's . ' 

Data Items 
Terms * 

Abbreviations 

Correspondence (LOGDESMO* internal) 



Library Conbral (LQ^GDESMO' .internal) 



T^eco rds 




Logical "Records - An array of physical oT^ecords to 
\ logically represent a record within a sector^/of a di/)la base 
Each such logical record includes attribute information 
co^ncerning -the subject of the'record.. These* attributes are 
Icxgi^cdlly arrayed in seven sections as follows> 



Record Identification Attributes fn,cluding 
J identification of the data bas e, the ^ sect-o'r , the p-ropon^nt 
organizat ioir, reference document,' 'docximent subSivis ion 
and da^te of latest recdrd change togetjier with, a un#qu^ i 
' '^six position numer i c . Re cor d * Ident if ica tio n Code C^4^Q) 

' ^ "Identification Attributes ^uth a's Official if&i^i 



Mnemonic Ab^.ev'ia tion or Initl^lism,* Document ref4ren.c^ 
d'esi3Jx.a:'tTon/, s.ynonym<?^s. names, stand-ar'di;z:ation» status. 

rormatlon, subject mat ter identif^catie-n, system^ config- 
uration control designation, scape,- Wejrsion data, e^; 

Reprfesentat ion AtPrifeutes such Vs^ype of ' - ' / 
representation, recording m.ode, length in ch^racterg, .type of 
characters, COBOL pi cture ^ signed quantity i^di<^tor, 
precision, ^ scale, etc. > . i \ * ♦ 

Location Attributes s^h- as.jdeVit^e t^pV^* 
organization of ^storage, ^ccesiB method , 3,^v^^'&±%£tf. f 
algoritkm, act ivity * address-^v-b lock siz^^, Storage t)hy^icaj. 
sequence^ and directory alia^e^s. 



Relationship Attributes * including 



*** Logical 'Structure /VpJointe/r. to subckivisionstf of 
; subject 'recbr,d with.in J single'! system.^ . - ' , V ^ ^ 



r 



-I 



Me^ 



ER^C 





^irecord ot"^he"Tiame 
Xtecord is a memW 



- pointer/ -t o • it.e x t "h Ig h e s ^ 
(y stew 'under which. 'the 




SO „ 



LOGI)RMS 



IV. CONTENTS AND PRQ ^ DUGTS .CGont'd) 

*** Interaction - pointer to a related ltem*kt' 
equal hierarchical leVel In a different system. 

** Organization Attributes such &s expected 
occurrences, ma^timum occurrences, e^owth factor, frequency 
^ 'Of usey^verflowy priority, and stiktistics, \ ♦ f 

. .** Securit y Attributes incluO^ attributes relating r 
^ to: * • ^ 

, ' Security o^ the system ' ' * \. . ^ 

*** Security of the. data content 

i ' ' ' ' . ' . • 

*** Acce'ssaothority * • -.. 4^ 

*• - 

***^Data Sburtte,' UpdK^e,r anjd Defii^L/tipn Responsibility 

*** Prlvaxiy Considerations ^ . . • , ' 

*** Freedom of Ihformat*ion Co.nsider^tions 

Integrity Attribute^ such as validity, consistency, 
reasonableness, propagation set, completei^ess, .reliability', 
recovery and ' r ef ^fttion . , * * 

/ , ' ' , ' - I : . 

' * ** Cost Attributes including such as ^ development , 
d^esigii, ^produ^tion, overhead, maiftt-enance distribution, 
com^municatioris', retrieval, and supporT^ costs , ^ * 

* ' ^ * *^ 

• * Tables - 'A series of thir ty-eigh.t CtablesKAre incorporated 
in the data base which pTovlie clear, text t r a^ sWatiTn f co.d.ed 
attributes and are used to edit inputs both as to ac^ilVacy 'akd 
validity ot select combinations of codes/ • ' ^ A • , 

Program Segments are als6\stored in the-data base. * . 

Data Relationships . / 5:^ , • 

* -Physical records- art . storeid Indelc^^d- to* ^n internal, control 
number. '. * • • V / ^ * 



, * Logical recor4s' con'sist of s^s -af physical^Tecords .-index^^d 
t'<> the, same internal control number/ * 



. * • Table recordk are.XikeWis^ logical records' consisting of ^ 
thtee phy8ica:l record^, one* for the .data code, t'he second for^th-e- 
abbreviatioh and t^e th±rd^;f 6'r the dat'a valpe. % ^-^^ 



IV. 'COyiENTS AND PRODUCTS (Conf»d) 



By reason- af the ,indexing of attributes internallv, 
♦it i^v^possible to query on a«^key ancT find aJl, records r#l^ted 
thet;e.to. Vii^tually all attributes are key. Query is on a 
boolean and/or/not thus>f acilltating seTective retrieval. 
Additionally, th*e syst^ automatically develops descriptor^ 
•(key word) indexing, of thjS pfficial and synonymous names thu-s * 
offerifi^ increased' potential f6r r,elAting records. Further, 
.tfte system d^velo-ps invisible stemmed de&eriptors of selected 
key^ entries (e.g.,. first five positions of key word; first six. 
positions of synonymous name key word; first, four po^itio'nfii • 
of system control designation; etc.). ^These further facilitate 
selective retrieval and avoid grammatical var ia*nce's'. _ \ 

Report Prodiftts - • « , . * * ^ 

Report products, at thfe.. pre-sent time are based uppn ad-ho^c 
queries, "in this re*gard, it should' be noted * that tlje . query ^ * 
feature of tha systeiQ permits the user to 'define the-search ^ 
strategy, prescribe the sort key 'and delineate the .gr^int ^ , 
specification including entry of fixed labels * It^ls plann*ed ^ 
that program segments wil^r be*w^itte^ to ^p.r^ovidp necessary . 
preplanned reports. ' '"^^ * ' " ^ ^ ' * ' 

. >: * * * ; ' ^ , • ^ ) - • ' . ; ^ 
OPERA'D'XONAL CHARACTERISTICS : ^ 
'^n- . * ^ . - 

Data ColVect^in 



' . * All LOGDRM^ updeites ar:e accowplAshed by direct on-line ^ 
entry to the data b,ank* with 4o sinteriyedi^te handling. * • 

* ^ Add (cr^^te) act^feqi >r^ j^gjB^^^^ entered in two - . 
operations. The f irst ^"jpSeif^j^eg. numbe^T of lo'gical 
reqafds w^-th commoti dtt-rilju^jg^sf^ J Th*e^ f o llow-dn 
acrion is an update to add' tT^^^i^nique (.variables) attributes 

of each record, ^^he ^rogram.\£3:p> additlo'ns p^ro.mpts the field- ..' 
'name and solicits an entry or o.a[xri.a^e.; re.turh?^ Ascontrol 
matrix monitors the appll cab,il i;f y; of* a^ributes to a* particular 
'segment. ' ' ^ ' • . V-, - ; ^ ♦ ' ' ' * 

Changes are entered Inj^one of ^two modes. ^ Mass cKa^ge 
of mulitiple records with ide^n.tj^c'al information is accompliah^d 
as a single action. UjpditijigT.of Srecords requires identity* of 
the fieldname to be cha^nged and whe^; read^ the entry of ^he 
data applicable to the* specif7i*ed..,attributfe"T^'- " \ 

* > ^ "aVv ' . ** \ V 

* Edit /validation c^*|rol<* using tables /prevents etltry • 

of invalid codes *ori . code combinJ^t^ions . ^ 
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OP-ERATIONAL CHARACTERISTICS 

* Changes to text such as Official Name, Synonymous 
Names, Definition, and Remarks are'^m'ade with a *text editing 
routine which ^allo^s for Insertion, d^eletlon, or replacement 
•of only the changed characters without requiring any actio^ 
on 'the unchang.ed portion of the^ text; 



X)peratinq Mode . 



* LOGDRMS Ijs organized In three subsystems; (a)^ update;^, 
(b) query; and (c)''batch processing .products . 

' ' ' ^ .\ ^ ^ 

All data updates (additions, changes , deletions) are 
pertormed on-line dlre'ct ^o. the databank. 

Query Is performed on-line interactiv-e ^with ^sear.ch . 
strategy defljied ''in • terms df fleldnataes and Utey values 
utilizing 'boolean and; or; and not. . ■ «; • ' 

K ' ' ' \ 

Batch processing prpducts are^ developed by extrapt^ng 
data base tecox ds'^^nd dumping sam^ on 'a magnetic ' tape in* 
response to je ^query command.* The' m,agne tic tap&s ar.e batch 
p^oc^ssed aqfcK prepared ^or ent]:y into Gompilter Output Micro- 
film (COM) equipment which produces flV^ster microfiche which 
in turn are?* copnie'd and dlstr^lbuted * *^ . 

Interfaces • . ' ^ * 

* y^Lt the present time, LOGDRM^ does not directly 
inter.fac'e with any other system. ^ 

, Future planftlng f'Or* enhancement calls for tape 

products fro^ systems ^esfgn cente'rs.to be batch s^loaded - » 
into^ Lt)GDRMS . Additionally, data teVmlnals are' to be 
installed" at system' design centers to^ tiake the LOGDRMS avail- 
able "on site of* sy s tem • developnbenf ^and *to eTl'minate the need 
for hard copy (microfiche) pubXica*tions for screening pur.poses. 

SECURITY- 

M ^ ^ ' ^ 'f t \ . 

ftestricttpns on Use v * - \" ' 



""LOGDRMS is -designed to document unclassified information 

- , Res tr'ictions are included 'by password 'controLrf>on 
update or query. Since sorting Involves so much CPU time. 
Separate passwords control who Cran. Sj^t retrieved data. • ; 
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VI ^ SECURITY 



Privacy Act Cofil^i derat ions " ' ' 

A complete- sect'loii9»6!f a logitaV rec^oTds is devoted to 
security Attributes Including privacy and- fre.edom of_, infor 
mation cbnsideratioris . * '"• '/ ' " 
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-Department *of Defense - U.. S. Navy 
Navy World*Wi(ie3lllltary-Cominaiid. and Control SVstem 
' Standard Data- Element Syslfem ^ 



STADES 



\ 



.9 



§5 

83 . 



ERIC 



1 



IDENTIFICATION 



Office of Prime Responsibility 

The ^Standard Data Element System (STADES) was developed by the ' ^ 
Navy* Reglpnal Data Automation Center, Washlrrgton, DC (NARDAC, 
•WASH., DC), (formerly the Naval Command Systems Support Activity 
.(NAVCOSSACT)) to. support th^ development, documentation, Imple- 
mentation, and control of the" Navy World-Wide Military Cofemand 
and Control System (WWCCS) • For Information on STADES contact: 

Commanding^Of fleer \ 

Navy Regional Data Automation Center,' Washington, DC 
Attention: Code 70,3 (Mr. Frank Tagler) 
J Washington Navy Yard, Building 19'6 
Washington, DC 20374 

Telephones: AUTOVON: 288-3629 /' • 

•Commercial: (202) 433-3571 

Documentation * v s 
— X 

'System documentation is internally dev^^^loped and maintained. The 
principal publication for the Navy WWMCCS Standard Data Element 
System (STADES) is NAVCOSSACT Document Number 88T001 TN-01 currently 
being revised as a NARDAC, Wash., DC , pulj'lication . 

\ 



SCOPE • ^ ;» . 

Reason for Implementation ' 

The World-wide Military Command and Control System is deslgped to 
promote commonality of •computer programs and systems across command 
lines. An essential part of this effort encouraging the use^of 
existing data, data structures, and data files in Qrder to simplify 
Interchange of data and 'programs . Thte >[avy WWMCCS Standard Data 
Element System (STADES) has been designed to. facilitate this ^fort 
and to ease the problems of determining the structure of data and 
data codes that are used in programs and systems designed for WWMCCS 
use particularly when such data have been used iin* previously developed 
projects . ' . ' V ^ % . 
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^11. SCOPE (ContM) 
Responsibility 



The Navy Regl6nal Data Automation Center, l4sh., DC (NARDAC, 
Wash., DC)', Washington Navy Yard, an element, of the newly formed 
Naval Data Automation Command (NAVDAC) , "^Is responsible for manage- 
ment, maintenance, and promulgation of' the Navy WWMCCS ^andard' 
Data Element System CSTADES). a part of this function, NARDAC, 
Wash., DC:^ ' , , ' 

. * Has established tlje initial centralized NAVY WWMCCS- 
standard data element file from data elements in SEGNAV 
Instruction 5200.26a,' JCS Pub 6, JCS Pub 7, Federal 
^ Information Processing 'Standards (FIPS) and the DIA 
IDEAS file. ^ ' , _ 

* Has' developed and is maintaining procedures for the 
Navy WWMCCS STADES using RAS II .to provide: 

** Efficient and 'ef fegtive storage, indexing and 
data element classification for centralized NAVY 
• WWMCC^ data standards. ' 

Responsive inqi/iry and retrieval techniques for 



use by. a local WWMCCS data manager". 



• * Determination of when local data element development 
should be authorized. ' , * 

* Promulgation of RAS II and files, including updates,^', 
to Navy and Navy supported users. . * . 

Record Association System (RA&) 

The. Record Association System (RAS) II, the program system used 
for ipaintaining. the WWMCCS STADES, is an automated cataloging ^ • 
and" Indexing system with extensive query and retrieval 
capabilities. 4*he design' of RAS II is based updh a capabil- 
ity which allows development of m^fny separate dajta baseis 
(modules) which are used independently or merge4/ln selected 
combinations. In this manner^ each user caiu control* and 
maintain both EAM (Electrical Accounting Machine) and computer 
operations required for his use of the SAS II. > However, the 
users modules ar^e considered as mergeable files of an overall 
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SCOPE (Cent'd) y . , . • . . , 

RAS II data base* Use of one set of re^cord formats and progra^ms 
'in /RAS II facilitates the exchange of information among all RAS 'II 
us6rs. Individual access to the modules by any RAS II user is 
coordinated and accomplisbed by the NARDAC, Wash,, DC RAS II 
5taff. 'The NARDAC, Wash,, DC RAS 11. staff also maintains' two 
modules. One contains a file of approved standard data element$ 
and related features 'and the, other a file of, infomration on all 
approved standards for ADP, Th.ese- modules are' available to all ^ 
users for automatic merging with their respective data base 
modules,. This capability eliminates redundant^ preparation of 
approved standards data by RAS II user^, ^ 

When RAS II is used as a data element library system, initial 
investigations reqifire that analysts collect information 

* describing data systems -or subsystems, £he data files or reports. 

^hich are part of the systems or subsystems and the data chains 
and data elements which constitute each file and r,eport,. Each 
data chain or data^elemexit is encoded so as to reference its 
related data chain standard or data ^lement standard. Updates 
to a RAS II Data Base are^ facilitated by the automatic assign- 

•laent o^^ a -permanent key (Record Identification Code) for id-entify- 
ing each record , . . " • 

Three types of printed foflrms are used by the collectors. When 
the forms, are completed they ,are submitted foi* r-eview to a central 
coordinator familiar with both, I^S II and' the system. « Upoh 
c'ompletion of review, the forms are returned to the collectors 
fo^ keypifnqhin^ and verification., ^Sorting the cards prior to 
listing is optional but makes proofreading easier, ,The listing 
of the punched cards ,is reviewed by the collector and corrections 
or additions are provided as needed, ^The completed cards are . 
Submitted by the collector to the RAS II maintenance personnel 
for. a .generate o^ update comput^er run,. The resulting listing 
§hows the records modified by that run and any input errors 
encountered. Separate" programs are used to format and list all 
,or part of the data base. Catalog and retrieval runs are made 
When summary information from the data base i's desired, * 

\ ■ , - 

RAS II can also be employed as a, tool, for operations research ^ 
effoi;ts related to, data requirements and data resources. 
Application of the RAS II methodology to define' the element? 
^of system data requirements and data resources provides an 
organized structure foV analyses. Through the analysis of 
RAS II outputs redtindant data reporting "can be •f9und and 
information requirements can be mashed to existing data * 
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II.: SCOPE (Cont'd) . 

. RAS III, an updated ^version of RAS II, allows for online inter- 
active' query, and xxpdating' of the RAS data base. 

• • . / , • • . ' , ^ 

STADES Procedures 

— T" ' ■ - ' ^ ■ 

STADES is e'ssentially /a. set of procedures governing- the develop- 
ment "and use of the data content of' RAS II files wi^th special 
emphasis on review of data elements and their related features 
during •specif ied eyents of the systems development life cyple. 

The Data Element Qictionary ^ ' , ^ ' ' 

* TThe Dat^ Element Dictionary is a structured .output product of 
the system used to coiranunicate information. pertaining to standard 
date •elements and related features, to various classes of users - . 
However^ it should be noted^ that the RAS -11 capability allows 
for output of a wide range of information products other than 
the data element dictionary. 

lit.. ADP RESOURCES ' . ' 

Although RAS II is available on the UNIVAC 1100 series, IBM 360/S70, 
and CfDC 6700 wit^ slightly different capabilities,' the system for 
Navy WWMCCS is rbn on the Honeywell 6000 series. , ' 



Hardware Requirements , 

* Honeywell 6000 series.., 

* One (1) ^magnetic^^tape.. 
^v,'^ Three (3) tape drives 

^ * One (1) card printel: 



* One^) line printer W:^ 

* One (1> d^ta terminal V;' 
'* Core memory: less than 29K 

* Operating System: -Ho'heywelli dCOS* 

0 A » 
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ADP RESOURCES (Cont'd) ] 
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Software" Requirements 

«* All- programs are^vritten for ANSI COBOL 

f 

' * Utilizes Internally developed RAS II programs in 
three distinct blocks: , • 

** Maintenance programs for generating and updating^ 
the dat.a base. . / , ' 

** Catalog programs for formating and printing the 
, data base. * ' 

^ Retrieval programs which prQvide various query - 
capabilities 

CONTENTS AND PRODUCTS . . • 

Purpose 

Id 

RAS II has been implemented on. Navy WWMCCS computers^ in support 
of STADES to "provide; 

* An automated inventory of NAJTY WWMCCS data element 
information ' ^ < 

* Indexes of this information 

* Catalog Report Generation Cd^ability 

* Query/Retrieval Capability 
Data Relationships 



RAS is an automated data storage indexing and , retrieval system. 
Its primary use in the Navy is to ma'Intain data element librari 
by- generating files of data elements and related information. 
Indexing the d^ta elements, generating data^lement catalogs 
an4^ retrieving data from the data element riles. These files 
aT?e modular allowing separate organizations to independently 
develop .thei^r own data element librarieAp^nd yet be ab'le to 
,4hare data or files,' by^ aotpmated 'means , with other RAS ^ata 
element .libraries. These interacting data el'ement libraries 
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CObflENTS AND PJIODUCTS (Cont'd) C 
' !^ / ■ ■ ' 

.make up a Navy-wi^e data** element, libraty system. The dat^ . 
stored In data element files are* retrieved for Specific analysiis, , 
design, and data st]andard-ization purposes. The^data is indexed 
by as-signed cl^^ssif^ications 'and by ke3rwords. Logical associatioits 
of these indexes.^cc5mplement a query capability for retiMeval o^f 
the data. Catalogs, reference indexes, and' si)e*if ic retrievals 
of data, may be generated. RAS is stiff iciently flexibLe for storing, 
indexing, and retrieving data on entities other, fhan data elements 
and related features. It /i^^jiised for document catalogirig and , 

'Report control. ' , 

^ \ . ^ r ^ ^ 
Data Organization , ' ' . 

The WWMCCS'STADES contains information about :^ 

9 

* Datk Systems and Subsystems ^ ' ^ ^ 
*' Data*^ Files ' ' ' " * • ♦ . 

' * Data Record Types . , ' ' ' ' ' • 

* Datalis^e Identifiers -arid Data Chains * 

* Standard Data EdRehts and Standard Data Chains. 
RAS Programs « ' 7 ' 

* Four maintenance programs ' ' ^ % 

* Two maintenance ijrogratns for- Distrl?bjitive Data Base 

* ^ One associating program providing five reference iodexeA ' 

* Six catalog report programs 4 * * 



* Five basic retrieval^ programs - ^ 
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^ * , Two interactive programs ' 
OPERATING MODE • " 

Data Collection ' * - ' • ^ * . - 

*' Creating^an initial regcord^ is» performed 'on a batch basis. 

\ * . STADES 



OPERATING MODE (Cont'd) • ^ ^ * . 

* Changes to existing records are processed on a batch' basis 
(RAS II) .and/or on line in the case of facilities utilizing the 

• RAS III Interactive yersion. ' . 

\ * .Controls are built in to. edit updates and to control' inputs 
^1 only from those sources authorized to update the* records 
involved. ' , • 

Operating Nod'e ' • ' 

» RAS II is designed for batch* processing (update, quer-]^ 
and display) . . ^ * - 

"* RAS III provides on line interactive query capability 
as well, as on line change capability. ' ' 

In^terfa^es 

The WWMCC^ STADES is designed to interface with user sy^-ems 
(e.g. / WWMCCS," CINCPA6, COMSUBLANT, DCA JTSA, etc.). ^ 

SECURITY . ^ * ' 

' — ' ^ • - ' » 

Restrictions on Use , 



* STADES includes provisions for recording the security 
classification of the data or entity being described^ - 

^ * STADES also includes controls to assure that only 
authorized activities can introduce or update records. 

Privacy Act Considerations 

Considerations of privacy ca\[i be incorporated in remarks notes 
of applicable records. 

\ 
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USDA Data Base • Directory ^ ^ 

I IDENTIFICATION . * / ' 

"The tJSDA Data Base Director^^is being developed by the USDA^/Of f ice 
of Automated Data Systems (ADS) . The directo^ry was first designed 
ia 1975 ^to provide an inventory of on-line app^licatio^s operated by 
the various independe*nt agency data processihg staffs. The devdiop- 
ment^of this inventory was conducted by the:^ 

^ , • Plans and Policy Division * ^ ^ 

""^y^ Office of Automated Data Systems * / 

U. S. DepartmWt of ' Agriculture ' ^ v. 
\ * Washington, D/.C. 2025p - j 

p- ' . ^ * 
' * Roxaane Will|.ams, Director W^lar^s -and Policy Diyision, ADS; USDA^ 
is the contact point for information , concerning the Data Base^ 
Dir^ectory (202/447-2118). Copies 9f t-hei data b^^e d'esign used tb 
support .this inventory can be^ob^ained by contacting ADS directly.. 

II* scope ; ' . ' ■ * * 

In 1972 the Department conducted a detailed survey off ^pr'ogram data . 
requirements. Both manual and^automated 4at^ were.,identif ied accord 
itig tO' the Departmental programs which' they si|ppf&rt. The following 
data a4:tributes were collected^f placed on-line on" a 370/145 for 
retrieval, and published for ^^formation interchange in tHe USDA 
Data Inventory: title of program data requirement, descriptive 
abstract',/ major data elements, source *of data and processin'g mode. 
Tfiis* initial inventory was conducted to identify potential common 
interest data; thus, supporting th^ Department's mbve into the data 
base (DBMS) environment. Now that the Department has transaction 
proctessing»and data base management capabilities, it has becpme more 
.important to"^identify common dlita use afnd to, catalog on-line data to 
inci*ease information exchange'* . 

The USDA^ Da.ta Base Directory (DBD) is one tool which ha^ been 
' • developed to augment the data management heeds of the Departmental/ . 
-Agency Data Base Administration ?DBD) statfs. The 'DBD was created 
as a Data Resource Management -^System or tool which can provide DBA 
staffs ,with information about on-lii)e applications neecied to manage 
data bases. ' • C * 
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— " - — — - ^ - ^ ' ^ ^ 

Thfe objectdves and operational uses for the DBD.are'to provide: , . 

, Individual agency access-to-information about existing ^ 
automated data in support df data 'interchange within th^ 
Department.. * ' • 

, . Computer qenters with sgftware utlli2:ation figures. 

* . The Departmental DB^^taff with a global view of process- 

ing, trends. , * J • . . 

. The DM staff with an inventory of data base's Department- 
. • wide. ' ^ ■ .-1 . 

The DBD was developed in 1975 as' a follow-up to the 1,972 USDA Data 
Inventory' study , The DBD C9ntains information on approximately 
thirty--five data bases to date; the inventory has just been started 
and currently reflects only a small percentage of ,the Depar^tmental 
data bases. The present structure of- the DBD is under review#.by^ the 
agency data base ^nanagers and baSecPon experience to date, is 
subject to modification. ^ ' ' ; , ' ^ - ^ - 

ADP RESOURCES • , ^ * 

The USDA D^D is operational on an IBM 370/168 using batch and 
on-line processi^ng through TSO into 'a single user version df the 
Data Base Management System (Systenf 2000 •o^f MRI Systems Corporation). 

CONTENTS AND^g^UCTS ^ * ' ' ' 



The -data relationships utilized by the USDA DBb inclufle: 

. . . • ' 

A repeating group concept using System 2000 that ties each 
data base or g'roup of data bases to tl)e system which it 
'supports — shqwing the title and description oE^ the- system 
and the title arid description of the supporting dat^ bases, 

. The' major data elements contained iiT each data base. 

. . 4 ' ' - * 

. Titles ^of reports generated frqm the 'data bases. . 

. List of USDA agencies other, than the owner agency inter- 
est;ed in the data bas*es. ''^ ' , • ^ 

/ ' * » r • • 
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O'PERATIONAL CONSIDERATIONS 



V 



Data collection 'for the DBD is aecorfipJLished using two methods. 
Fijyst, USDA procedures for development of onrline data bases require 
*^bmission of data* base specification to the Departmental DBA staff. 
These specifications and documentation information are entered into 
the DBD. Second, for data bases already in exi^stence, agency DBA 
staffs cQllect the infom^tion and forward the data to the Plans and' 
"Policy Division of ADS for inclusion "in the DBD. <> - 

. • • ' . V 

VI. . SECURITY - * . ' 

This data*is then, entered vi^a TTY compatible terminal into the 
f System 2000 data base. Control of the DBD access is accdmjilished 
using the Sys*tem 2000 password security. 



VII. USgR CHARACTERISTICS \ ^ , 

The Office of Automated Data Systems is'^a ataff office with total 
responsibility for management of the Department's Dat,a Ptocessi^ng 
operations. ADS x^orks directly ^wittT^ the ADP staffs of the Depart- 
, mental iine agencies. ADS "maintains the DBD, each agency has copies 
of the QBD output, /^t present, the 6BD cixntains . inforination ab^t* . 
. * '* online data bases covering: . ° ' 

* . Name of prganization responsible for the data base system**^ 
. Agency contact . • * ' • 

. ^ • . System name > - 

f Data base name k ' . 

a . PrDcessing location ' ^ • " 

. Software used " » . ' « 

. Datar^ase size « - * • • . 

Dita base'' description • ' . 

. Major data elements ^ ^ 

• . Source of data elements 
^ Data use (which program it supports) ^ 

• <^ 't^ Data base report o ) * . 
■ • " . 'Update mbde arta frequency ' . 

. Other interested^ USDA agencies ... ^ • 

. Personnel data indicator , • v 

a . Security features ' ^ 

■ ' - * ^ 

This list is not all inclusive , and is-subject to modification as 
the Department gains mo*re experience in its use of the l3BD. 
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Any analysis of USDA costs would Be premature at this time since the 
existing data base is- s6 small.. The existing DBMS; System 2000, was 
adequate for our.need§ so that no special software acquistion^ costs 
were incurred. ^ ■ . « 

" ' *• * ' '94 I'OO ' * ' USDADBD/ 
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VETERANS ADMINISTRATION 
VA DATA DICTIONARY 



I. IDENTIFICATION 



The Veteraris' Administration Data Dictionary (VADD), designed and^ 
- developed by the Department of Data Management of the Veterans 
AdTninistration, 'was installed July 15, 1976. This system is the 
responsibility of the Privacy and Data Adminisiration Division 
(334), and for ififomiatio'n, please contact: . ^ 

Chief ,^ Privacy and Data Administration'^Division 
' 810 'Vermont Avenue, tN.W. 
Washington, D. C* 20420 

Phbnje: (202) 389-3034 • ' ' ' 

Documeniation, in the form of, a "Handbook to the VA Data Dictionary", 
js avail-able on f^equest, ^ This .document is primarily a user 's guide 
; .to the systefn. " ^ . ^ • ^ 

II.' SCOPE '^^'""^ 

The objectives of the VA Data Dictionary are:* ^ 

- . .To standjardize^data elements thro.ugh a data inventory, by 
• first identifying^and /then i'solajiing ^hose data elements' 
with, cdmmon definitions atDd attributes . 

, • . ^ : -^^ 

. To identify §ind eliminate and/or prevent redundancy and 
inconsistencies in data elements used .within ^YA ADP' manage- 
'mfent. ' ' / - ' ' ' • ^ , 

* , . to' provi-de detailed documerttatlon of da\i elements? to 

ihsare that all pertinent facts about the elements are 

^ ^ ' ; communicated 'directly and .concisely to both -ADP and \ 
non-^D.P management. ' , ' • ' - 

• ^ To aid VA personnel in^'deternjinlng the impact*of proposed 
and/br approv^Je'a changes, to data elements b'y identifying 
\ ' the programst^ master files and reports j*p which the data 
' elements appear.^ . . '^^ , ' * 

. To 'su|)port VA pei»sDnnel engaged in. designing, maintaining, 
and managing automated systems; by providing easily 
comprehensible reports describing the VA data resource. 
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The \fA Data Dictionary is an information tool by which the Veterans 
Administration intends to fnanage and control the data resource. This 
information *too1 is an automated, central collection point for a 
current and cbmpTete description of all VA data elements, 'in ^ 
addition to this dictionary feature, the system is' also a data- 
r directory in that data elements are' linked to application systems, 
user programs, master^ files and reports'. ' ^ - 

The total number of data elements in the VA is appraximateTy 82,000 
elements. As of November, 1976, there*exist 374 application systems 
min the VA. This .amount can easily be han,dled by the VA Data Dictionary 
"a time span of approximately two years is anticipated for entering all 
VA ADP applications into the VA Data -Dictionary . 

\\\[ OPERATING REQUIREMENTS • \, 

The VA Data Dictionary. is installed on an IBM Series 360/65 Computer, 
running under^ OS/MVT. The system requires 90K bytes of main storage, 
a single 2314 disk (to be 'used for intermejliate work files), two tape 
drives (three may b^ used as an alternative to disk for purposes of 
spooling output) and a printer. Optionally, the VA uses a Xerox 1200. 
off-line printing system. 

The dictionary programs are written in ANS COBOL. 

Jhe software supporting the VA Data Dictionary is non-^proprietary . 

IV. ^ ' CONTENTS AND PRODlTCTS ' ^ . • . \ * 

-A ^' 
The VA Data Dictionary Master File, stored on^magiwetic tape, is 
organized by sequence number within transaction code, within Permuted 
Word (key' identifier for a data .element) , .within aoplication acronym. ^ 
The record length is 125 positions, blocked 8. There are sev4n 
multiple fixed length master records that contain:* specific informa- 
tion on a data Elements (such as n^me, description, values, users, 
application programs affected); element content of an application's r 
master files; and data elements that are used in the creation of ^ 
agp]i cation system T^eports. A Summary record follows each Application 
System storing necessary statistical da^a. ^ ^ ^ 

The system i$ designed to run in a batch mode with sequential update 
and report processing to occur ^minimum of twice a ^eek. It should 
be noted that frequent update oT"the master file 'will provide users 
with the most current, up.-to-date information on data elements within, 
their appl ication(s) . ^ 

"Semi-annually the entire VA Data D>ictionary i^'printecj. : 

. ^ , , * 
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The VA Data Dictionary generates several reports on the data element 
contents of VA applications. Three distinct report types are produced 
"Element Description Report", Master File Report", and "Report Content 
report. These reports are ^geneihated bi-weekly as changes occur to the 
infprma^iion content of a data element, master file, or report, and 
semi-annually when the entire contents of the Data Dictionary is 
printed/ ' • . 

The primary report generatefty tfie VA Data Dtctionary" is an Element' 
Descri4)tion RepaK which describes each data element within a VA 
application. The information provi'ded* injcludes: Permuted Word (key 
identifier of the data element); Element Name; -Source Responsib'ility 
(organizational element that controls or manages a VA Program 
Application);" Narrative. Description of the Element and its related 
values; Application Programs and VA departments that use the Data 
Element. ^ ' • • • 

As stated previously^ the VA Data Dictionary 1 inks data elements to 
application master files and reports. The "Mas^ter File Description 
Report: identifies, by ^poli cation system, all data el-ements stpred 
within a mcister file in i^ proper sequenced An "Element Structure 
Report: identifies, for ea,ch report generated by an application 
system, all data elements used in the creation of the report. 

A by-product*of this dictionary is the "permuted Word" Report^ The 
"Permuted Word". Report .lists al 1 VA data element^, in Permuted Word 
sequence, and the application system that uses the data .element. 
For a brief fexplanatioti , this provides a' means of cross -re.fereacing 
data elements common to' multiple* applications. ^ ^ 

The -update program generates separ^ate lists, by application systems, 
for all accepted or rejected transactions. -.In addition, a s;tatistical 
summary report lists, by application system, individual totals for the 
number of elements, master files and reports contained in the VA Data 
Dictionary Master File for' an application, in addition to. other mis- . 
eel laneous statistical data. . 

The VA Data Dictionary -provides a query facility through the use of 
optional reports. .These reports, run on an IBM Series 360 cbmputer 
or other compatible computer hardware, consist ofospecific application 
requests or partial reports about: (1) a specific ^ata element or 
(2) the con-tents df a specific application master file,'4.or (3) the 
data elements usec^in the construction of each report. Storage of 
the Master" Files on tapes makes it very conduci ve^^to distribution of 
these files to the various§VA Dat^ Processing Centers thVoughout the 
United States. This will permit,Veach Data Processing Center tj3 obtain 
any portion of the Dictionary that is in current demand. 
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The system does not have an RPG capability ilor provide any in1 
active activity, special utilities o< iaterfaces with any othc 



system. Ho 
.extracted f 
men.t" Systen 



iter- 
iny other . 

/ever, at a later time, certain information may be 
:'om the system and used as input to a^Data Base Manage- 



OPERATI0WL' CONSIDERATIONS 



f 



The organization responsible for m 
applicaftion (the' "Responsible 'Source 
persor^el to prepare input data to 
peopli^, commonly referred to as "Inforijiation 
f pii 1 i 



m^ent and control over a VA" 
v^ill. designate certain 
^^VA Data Dictionary. These 



be 



_ Specialists", should 

ar with and TcnoWl^^dgeable o.^^^he information contents of 



their cippli cation sys$em$! 



'.1 



Data W 



|;Ctionary System initially 



Data to bg<\enteredylritO' the VA 

is 'obtained fpm, existi ng system docdrfentation found in manuals, 
circ^lars^ and, direc'tives, or throu(5'b ^tie expertise, pf 'various 
individuals.' Appropriate systems personnel ^it a VA Data Processing 
Center fDPC) may provide data such as;f appli coition program names, 
master ,files and reports content. Tq/s data gathering and pj'epara-'^ 
tio'n cin be phased, in at different' time periods. Th?it is, data, 
elemenjfc name and description will establish a data element on the 
master fil-e with additional informatii^' te be provided at a later 
time./ ^ ^ k ^ 

Inpuyt to the D^ta Dictionary system is accomplished through key- ^ 
entfy equipment using seven different trASsaction formats. . ^ 

Procedures have been' established to insur§ Integrity of data to be 
si/bmitted to an processed by the VA Data DKctfonary. Jheseonclude \ 
irious circulars and the Data Dictionary handbook. Continued usage' 
theafcictionary -by the responsible sources of info,rmation will 
/enhSinc^he integrity of the dictionary.' . ^ ' ' 

The VA Data *Dictiohary edits not only for Validity, but completeness 
of data submitted for processing. Any free-formatted areas are not 
edited.. Back-up to the master file is provided through retention of, 
father grandfather master files and tfansagtion tapes.*. 

' SECURITY ' ^ % 

Procedures have been established jfor the developpent of an access . 
to the VA Data Dictionary. . Access is avaflablfe to all authorized 
personnel in the Veterans Administration. Tape copies of the master 
file are available to all-DPC's for query and optional; reports at a 
user's request. Since the dictionary is ar "hard-copy" version,' 
limitation of access is not intended to be restrictive; since at the 

intended to be a data base system. A 
to indica.te the security level of feach data^' 
however, it is not an. active feature im the 



present .J^ime, it. is not 
provision has beeKjnade 
element. A.t this time, 
el emenr descri pti on . 



ERIC 



/111 



VADD 



\ 



All input documents are 5ubmitte,d through the Privacy and Data 

Administration Division for review, analysis and control.^ Computer 

'generated' reports afe/di§tributed to authorized personnel* according, 
to established procedures. 



VIL USERS 



The VA Data Dictionary is a useful ijiformation tool, to be used VA- 
wiJe and ribt limited to a specific application or geographical area, 
^ecausefdf the layman's-'language^description and definition of data 
el^menits, the dictionary may be utilized by ADP oriented as wetl as 
non-ADP or.iented management and staff. As a result, the dictionary 
may b^ us^d as a. reference point for communication among management, 
•^"Responsible Source",- u^ers, programmers and analysts. It also will 
be used as .the basic ingredient' in formalizing a data base system. 
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APPENDIX D 
SCOPE NOTES FOR THE 
NARRATIVE • SYSTEM' DESCRIPTIONS 



tD^NTIFICATlON 

Title . Full system title, 

B. Short Title . Commonly used abbreviation o^ acronym Identifying 
the system. • ^ 

C. - ^Organization and Address . Idehtit^ o;E tl^e o'rganizatioji responsible 
fbii^the development of the systety to th^ Branch or Division lev^l 
and complete mailing *address. ^ 

D. * Technical cWLact Title, OrRan/zation; and Phone Number . Identity 
, of the office to be cpntacted yto^j^4etfailed inforraat^on on the ' ' 

subject-matter or op'erationaYaspect/s of the system. Include area 
^^code and phone number an4 phcstie system^ (i.e., FTS, AUTOVON, , 
commercial) . 

E. DocuriieAtation Type and ^Availability . Briefly describe' available 
documentation. • Classify die type o^document' (i.e. , itunction^l 
description, system desigrt specification, user manu^J etc.) 
document title, document /reference number,, and indicMtfe th6" 

. "availability of documentation .listed. Identify the contact point^ 
for "obtaining' ddcikentatfiorf. 7 ~^ " ^, ~ 



SCQPE 
A 



'Background . B-Ziefly ae^icxAbl Xh^ circumstances which resulted 
in the^ development of /a SSD/p/syste^, If^it is not the organiza- 
ti^Dn^s first attempt kt (Jrganl^ed data management, describe the 
'previous efforts: ^ /' / ' ' ' 

1. History, of DED/D/ sy^teiA if obta^^ned from another organization 
or modified an already/ existing^ system. 

2. Approximate month and /year in which major system. milestones 
.occurred or arej expeci/ed to occur. 

I 

3. " Reasons for adaption, / creatiTfff, or modification of DED systems, 

Implementation .Levlel , j Drf^ermine?' the -level of capability as 
listed and def^ifi«cj( in Section 2 of this report ^ The 'category 



selected' -shouldArafle<^'t 
in ,thB view of thA deVel 
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accurately the system's pr.imary function 
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III. ADP RESOURCES (IF NEEDED) 



HARDWARE RESOURCES 



Describe tfie hardware , , 

and software requirements of automated systems. The hardware 
resource section should include the manufacturer's name and 
model number of all computer main frames -on x^ich,to the knowledge 
of the developer, the system is installed. 




The operating system used and the minimum core required to 
process the system should be specified. Both ^standard peripherals 
such as disk and tape drivfes, and special offline devices, such 
as pa^fe printers gv. microform devices, which are needed to 
operate the system may be 'listed. 



Describe the software re'sources in two distinct groiip$'. the" . 
first group s'hould i^nclude any programs written by or extensively 
modified by the organization which installed the system such* 
as edit and update programs and report generation programs. 



The second gYoup should* include any generali^d software needed 
to execute programs in the first .group, ^^lihes^ would include 
data base management systems, generalized report generator 
modules, prpgram library facilities, and utilities such as 
--fiorts and* data- convert oa. routines . ^^--^ 



For each group the developer's name, the source language, its 
\ 'availability and its proprietary status and cost, if applicable, 
shouljd be listed. If a group of proprietary programs is involved 
it is listed as a group, not by component , programs . Only user 
modifications should be mentioned. ' . 



:i V . . ^CORTENTS AND P}lODUCf S 



a: 



Data Relationship Described 

■ ' ■ \ _ \ ■ 

In this fsection, all entities (as previously defined by task 

group 17) such as rep.orts files, programs etc., which are covered 
by the sy^stem, can be listed. .The relationships between the' 
information entities which the DED/D describes may also be 
^utl^ned. For example, if data elements *are telated to reports, 
OA files to programs, this may be recorded-^ 
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B . Data Organization : - " • > ' 

^ Summarize the content and organization of the DED/D and give a \ 
brief descri'pti9n of how it is physically stored and organized, 
and whfether or not° it is stored in machine readable form. 

"Lis-t, all 'files, tlieir primary purpose, and their content (record 
and *fi^eld)"- with sequence and access metfiods. For example, a 
•system ra'igh^ have one file which describes data elements and\ 
, another which describes reports. Fof ^each file list the fielos , 
for each record in the file such as element name, size, or tlas^,** 
or* report names, report data etc, and indicate sequence fields./' 
Specify the stq rage medium used for the file, i.e., microfiche, 
paper, tape, disk, ^c. * * 

C Reports and Products ' , ^ ^ 

v> ^ < 

List all standard products produced, by tTie system and b.riefly 
describe tfrem— if the .title is not self-explanatory. Outline 
any ad ho^c reporting anS query capability. 
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OPERATIONAL CONSIDERATIONS 



A. Data C511ection . ' ' . ^ 

•Cover the sources of the* data used to buii'd and maintain the ^ *^ 
DED'/D sucli as d^ta processing or forms ijanagement, data ^roces- 

- — sing users^ systems-design personnel dat^ Jbase admiaiatratign 

staff, etc, • • . ' y 

• ' Discuss the methods used to colle'ct data. Also describe data 
collection methodologies, ^such as reseatch through system docu- 
mentation, 'interviews conducted * by analysts, or the use of ♦ - 
special forms designed for the purpose. Describe t;he skill level 
and the prqcedures used in the entry and cipdate processes. 

B. ^ Operating Mode ' ^ ' 1 . 

Mention the system's operating mode, both update and query. 

Is it bajtch or online for* both or is it a Afxture? Briefly 
outline this capability. 

C. Interfaces * ^ \ 

List interfaces with other apf^lication systems or- generalize^i 
software'. /An example of this yould.be an interface between the 
DED/D and a financial managemei^t system' or a project control v 
system* . ^\ 
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A* Restriction on Use 

^ ' _ / 

\ ' ' Discuss any restrictions on use of the DED/D, tRe reasons' 
* / ; \. ♦ for the restrictions, and the ways they are enfoi'ced. List the 
^ ' • Personnel and offices who normally pecform •upd^tes.^.-^ . 

Privacy Act of 1974 Considerations - « 

Cover ;eny effects which the -organization feels that the^Privacy 
• Act of 1974 has had upon the way in which the 'dED' i^ xisei 
*• or constructed. " , ^ • ^» * 

y VII. UservCh^ractetistics 

— ' ' i / 

^ A> User Organization. Describe' o& the organizational relationship 

of the responsible organization to user organizations', and the 
l^v^l' of the responsible organization within the overall organizatibn* 

^- f)ata Use d/Maintained . List the information entered and ^maintained 

^ by the DED/p for us^ organizations. ' . ' ♦ ^ 

' i • ' '-'^ ^ ■ . 

^C. Reasons for Use. List the reasons for using tTie .DED/D by user 
' ' .o^anizations. ' ^ 

i • ' . , . / ^ 

VIll. COSTS j( OPTIONAL )^ :^^r^ "^^1^.. \ 

" Ay ^Coi^t . Sup ply any available e stimates of .cogt in^^M |nars which 

' may be heloful to pr-qspectlve users or developers^ in scoping 
resource cohimitments if they expect ta ^develop and^ maintain . 
. , appi:oximately the same number of data elements and expect similar 

'amounts ^of activity 'against' the DED/D. - ' ' ' . 

> ^ Incliide costs for equipment, software, maintenance/ and related 

support costs.* • . ^ " , ,^ . 

' .B. Personnel Com mittment. ' * * 

• « — ~ ' ' ■ ■ - - 

tist -the clumber and type or * classiMcation of personnel 
c * nsed during each* phase o'^f system development and operations. 

/ • ^ ^ ^ ' . y 

2. List 'Skill levels by type ot* classification of personnel 
• ^ • employed dur-ing development and operation. * i 

3* l-ist of tasks performed during development and operation. 
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IX. ' General Comments 



Include' additional^ comments which the dfeveloper wishes- to make. 
O ^ . , •• ■ -104 
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APPENDIX E / ' • 

The following' 'def in ttions ^^re Intended to prbmdt^e a clear understand-, 
ing of the meaning of each one of the Entity' Classes that are Ideritifie'a V 
y in this pilbliqatiori,^ It should be understood that what const|.tutie3 an 
^Entity Class i^ environment dependent. What one orgarflzation!^ay deter- 
mine as aopfopriate tlasses .of eatities and t^eir /Relationship" to one 
another m^ differ from what another organization*' considers appropriate, 

Plan/Program - An activity directed toward a common purpose^ obje^j^tive,^^ 
or goal undertaken or proposed by an organisation in order itb carry out^ 
responsibilities assigned to it. In many. instances the p?3n or progjtam. 
has its root in legislation or exs<4itive determination^^ (fe^ Plan ' * 
[Management] and Program [Management^.) , " " . 

Plan (Management ) - A documentation of management., goals together, with a • 
genial prescription of the manner in which such goals will be attained 
within a defined timeframe, > • 

Program (Management ) - A combination of activities undertaken by one or 
more organizations directed toward attaining specified paanagement objec- 
tives in ^iven functional and subject matter areas. Initiation of a ■ ^ ' 
ifianagement program is''normally effected by issue of a directive, instruc- 
tion, regulation, or other type of authoritative iVs^uance which prescribes 
the scope of effortfs, enunciates management objectives .an^ program policies, 
« assigns 'responsibilities , and^ authorizes the usJi^f resoipeeg for the 
— purposes-- o f -tite- program^; — • ^ ^ ^ 

; ' ' ' " ' •■ • . 

System - A composite of equipment, skills, techniques, and information 
capable of performing and/or supporting an* operation role in attaining 
^specified management, objectives^ A complete system i1^cludes» relafced 
facilities, equipment, material,^ ^serjices, personnel^ and da^a/information 
required for its operation to the degree that it can be considered a 
3elf-suf f icient unit in its intended operational and/or sup'poij^t enyirbnmfent. 

Application - The first level subdivision of a system consisting gf 'a 
series of processes or procedures devoted to accomplishing ^a specified 
'portion but not all of^rthe system pbjectives. In management ^ systems , 
applications are of ten identified a& subsystems. In* automated* data 
' processing systems , 'applications are frequently identified as either * 
subsystems or applicajfton systems,' 

Pro cedure - A series of precise step-by-stef^ processes within a4 appljh-^ 
cation which produce s^^ecified results.* The processes may he manual or 
automated or a combination of both* The termiiiology normally us^d to 
descrfbe an automated process i^. "computer prdlgram"; manual processes 
-are "tasks", " ' . • , ^ 
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Process (Operational) - the first _J^el_j^ubdiyision_^ ^_AEPli?.?tion^ 
' consisting of a systematic*. sequence of operations to produce a specified 
.result/' (See alsa Procedure) . ' . ' 

File -'A' collection of rfel^ted records which are treated' as a ^it;^ 
(With tlie advent of c^omputers, it. has now become' feasible -to collect » 
related records** of one or more files tbf be treated as* a unit to serve 
one or more'^ processes • TJii^ form of reUated file .structure is c^alled 
•a DATA BASE. In the event a 4ecision is made to record data bases' as 
a separate enfe;Lty class^ in a Dto^ they"^ should be recorded at a hier-- ' 
archically higher* level than fIlES:). , . ' 

Record - A collection of related Aata ^ements' treated as ^ unit. 

Record (File) - A collection of related file item^ of data treateiJ-^s a 
•unit. ' ' _ \ 



Data Element - A basic unit^f ideutifiable and definable infarmation* 
A fllata element occupies specific space on a folrm, report, or record. 
It has ^an ^identifying name and value or values for expressing a specific 
fact^ 1 - , ^. . * 



, Report - A product of a process which prbvides, a narrative, statistical^ 
or graphical presentation of one or more records and/or other information 
^transmitted for use in planning, controlling or evaluating operations and 
performance, and deterniiiiing policy ' ^ 

Form - Any printed design with ot wifEout text which, contains blank spac^g^ 

be Tilled ~irr"to~recQrd , collect, or transmit *one or "more recpYds"] A 
form completed by the_ entry of information may be a file Tecord, a * * 

document, or a report • ' " 

Document (Transaction) - A collection of related items of data treated 
as a unit for input to a system, application., or proces's. • ' 
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